[12] SHOULD (するべき) や RECOMMENDED (推奨) は、 原則として従わなければならないものの、 正当な理由がある場合に限っては従わなくても良いことを表す助動詞です。
[13] そのような条件に違反した場合、十分正当な理由がなければ、不適合となります。
[14] 日常語としての「するべき」や「推奨」は“どちらでも良いがした方が良い” 程度の弱い意味のこともありますが、 適合性の記述の用語としての「するべき」や「推奨」は、 MUST にかなり近い強い意味を持っています。
[10] SHOULD や RECOMMENDED は、 特定の状況においては当該事項を無視する正当な理由が存在するかもしれないものの、 その場合には予め何が起こるか十分理解し注意を払わなければならないことを表します >>9。
[11] SHOULD NOT や NOT RECOMMENDED は、 特定の状況においては当該事項が認められたり、 有用でさえあるような正当な理由が存在するかもしれないものの、 その場合には予め何が起こるか十分理解し注意を払うべきであることを表します >>9。
[23] 日常語としての「するべき」や「推奨」は 「どちらでも良いがした方が良い」、「できればやる」、 「やれたら良いが現実には難しいかもしれない」程度の弱い意味のこともありますが、 適合性の記述の用語としての「するべき」や「推奨」は、 MUST にかなり近い強い意味を持っています。
[24] SHOULD 要件には、原則として従わなければなりません。 違反しても良いのは、違反が正当化される十分な理由が存在する場合に限ります。
[25] RFC 2119 を参照している仕様書を参照していても、 RFC 2119 自体は読んでおらず、 SHOULD の意味を軽く見ている人もいるので、 注意が必要です。
[36] 逆に標準化以外の場面 (技術ブログなど) では、 RFC 2119 を参照して書いているくせにまともに読んでいないのか、 弱い意味で SHOULD が使われることがあり、 意思疎通に支障をきたすことがあります。
[26] 一般に、実装に任意選択の余地を与えるのは相互運用性の低下を招き、 好ましくないと現代的な Web標準化の場面では考えられています。 (他の分野では必ずしもこの考え方は普及していませんが。)
[27] 仕様書はできるだけ SHOULD ではなく MUST を使うべきですし、それが過度に実装を拘束して好ましくないと考えられるなら、 そもそもそれを要件として挙げる意味があるのかどうか自体を再考する方が良いかもしれません。
- "SHOULD"
- This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
- するべき
するべきという語は、実装に関しては、 実装の推奨ではあるものの要件ではないと解釈します。 文書に関しては、文書のプログラム化する時の推奨であり、 厳密適合XHTML文書では要件であると解釈します。
[39] specifications/unified-test-format.rst at master · mongodb/specifications · GitHub, https://github.com/mongodb/specifications/blob/master/source/unified-test-format/unified-test-format.rst#meta
RFC 2119、しかし
This document tends to use "SHOULD" more frequently than other specifications, but mainly in the context of providing guidance on writing test files. This is discussed in more detail in
Design Rationale リンク .
[15] 「recommended」は RFC 2026 の適応性に関する用語と衝突するため、 削除が提案されています >>16。
[18] RFC 2119 の助動詞を採用する仕様書でも、 >>17 のように 「recommended」はより弱い意味で使っていることがよくあります。
[38] Infra Standard は SHOULD を使うことを推奨しています。
[19] RFC 2119 の意味との衝突を防ぐため、より弱い推奨を表すために 「encouraged」、「discouraged」、「ought to」、 「good practice」、「preferred」といった語句が用いられることがあります。
[1]
XML Query (XQuery) Requirements (2007-03-17 06:39:09 +09:00
版) http://www.w3.org/TR/2007/NOTE-xquery-requirements-20070323/#terminology-should
[2] XML Query (XQuery) 1.1 Requirements ( 版) http://www.w3.org/TR/2007/WD-xquery-11-requirements-20070323/#terminology-should
[4] RFC 4835 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) ( ( 版)) http://tools.ietf.org/html/rfc4835#page-4
[5] RFC 4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) ( ( 版)) http://tools.ietf.org/html/rfc4305#section-2
[6] W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes ( ( 版)) http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#dt-should
[7] W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures ( ( 版)) http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#intro-terminology
[21] RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ( 版) http://tools.ietf.org/html/rfc5280
[22] >>21 は RFC 2119 を参照しつつ、特に説明なく RECOMMENDS を多用しています。
[32] Editorial: fix grammar and avoid "recommended" in note (zcorpan著, ) https://github.com/whatwg/html/commit/f4c4f386e55e24a7bfc7d48abbee3aa62ac56449
[33] XQuery 3.1: An XML Query Language () https://www.w3.org/TR/2017/REC-xquery-31-20170321/#id-conformance
[34] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#conformance-terminology
[35] Infra Standard () https://infra.spec.whatwg.org/#conformance