助動詞

要件を表す助動詞

[28] 仕様書における助動詞は、その適合性要件を記述していることと、 その種別を表しています。

[52] 例えば、「img 要素には src 属性を指定しなければなりません」というは、 助動詞 なければなりません (MUST) が使われていますから、 適合するためには「img 要素には src 属性を指定」することが要求されることを表しています。

[53] このような助動詞のないは、事実の文などと呼ばれ、 要件ではなく単なる説明に過ぎません。

助動詞の一覧

[29] 要件を表す助動詞
[32] 助動詞以外の要件を表す単語

[51] その他関連する語句:

意味

[48] 助動詞は、そのが当該仕様においてどのような意味を持つかを表すものです。 例えば「○○しなければならない (MUST) 」とあればそれが必須の条件であることを表し、 それに従わないのは仕様違反です。 「○○しても構わない (MAY) 」とあればそれが認められる動作 (の1つ) であることを表しています。

詳細は各助動詞の項を参照。

[49] 仕様の記述に利用する助動詞の選択や位置付けは、標準化団体仕様書によって異なっています。 Web を含むインターネット関連技術の仕様書の多くは、 RFC 2119 が規定する助動詞を採用しています。しかしその中でも、 WHATWG 等の近代的な Web 関連の仕様書は助動詞を用いた規定の記述を徹底しているのに対し、 IETF事実の文を用いた規定を多用し助動詞は限定的にしか用いないといった様式の違いがあります。

アルゴリズムの適合性の記述

[34] HTML Standard などでは、アルゴリズムを記述する際に、 その各手順で要件の度合いを繰り返し記述せずに、アルゴリズムの紹介文で一度だけ助動詞を使うスタイルが採用されています >>35

[36] 例えば、

To eat an orange, the user MUST:

  1. Peel the orange.
  2. Separate each slice of the orange.
  3. Eat the orange slices.

... のようなアルゴリズムの規定は、

To eat an orange:

  1. The user MUST peel the orange.
  2. The user MUST separate each slice of the orange.
  3. The user MUST eat the orange slices.

... のように展開できます >>35

[50] あるいは、「○○する手順とは△△である。」と事実の文の形でアルゴリズムの定義を述べ、 呼び出し元で「○○する手順を実行しなければならない」とすることもよくあります。 アルゴリズムアルゴリズムを呼び出す場合には事実の文の形の定義ばかりのように見えることも多いですが、 最終的な呼び出し元までたどれば必ず助動詞が使われているはずです。

適合性の主語

[37] 要件を表す文章は、その行為を行うもの (ソフトウェア) を主語として記述することもあれば、生成物の状態を主語として記述することもあります。 どちらの方法で記述されるかは、編集者の好みのスタイルや文脈などに依存するもので、 深い意味はありません。

[38] 例えば、「著者は、 div 要素p 要素子供としてはなりません。」と「p 要素は、 div 要素子供として持ってはなりません。」 は、同じ意味です。

[40] HTML Standard はこのような適合性の主体について言及しています >>39。 他の仕様書でも、明示的に説明していることはあまりありませんが、同じように解釈されています。

適合性に寄与しない助動詞の利用

[73] 適合性を記述する助動詞規定以外の注記や例示などで用いることは、 読者の混乱を招く好ましくないことだと考えられています。 にも関わらず、しばしば助動詞が用いられていて、たまに誰かが気づいて修正したりしています。 (それだけ英語話者にとっては日常的な語句である助動詞でうっかり使ってしまうのでしょう。)

[74] 例えば、「名前では姓を省略するべきではありません。 例: 山田太郎を太郎と書くべきではありません。」は、例示中に助動詞を使っています。 これは「名前では姓を省略するべきではありません。 例: 山田太郎を太郎と書くのは好ましくありません。」のように書いた方が良いとされています。

要求度を表す助動詞のマーク付け

[7] QA Framework: Specification Guidelines <http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#consistent-style-tech>

この W3C の仕様書のための指針では、 RFC 2119 の助動詞を使用し、それをマーク付けして明確にすることを勧めています (が具体的な方法には触れず、 >>8 を参照しています)。

[13] 今のところ xml2rfc (RFC 2629 の言語) で助動詞をマーク付けする方法はないみたいです。 (名無しさん 2005-11-11 05:20:45 +00:00)

WHATWG proposes class=ct and anne uses it in CSSOM draft.

[22] XML Syntax for XQuery 1.0 (XQueryX) (2007-01-19 07:17:16 +09:00 版) <http://www.w3.org/TR/2007/REC-xqueryx-20070123/#xqx_conformance>

RFC 2119参照しつつ再定義 (名無しさん)

[27] Transforming RFC2629-formatted XML through XSLT ( 版) <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extensions>

[70] SuikaWiki Markup Language (SWML) () <https://suikawiki.github.io/spec-swml/spec/#conformance-keywords>

JIS における規定

[31] 文章の末尾 要求事項の記述は、その内容が指示・要求、禁止、推奨若しくは許容のいずれであるか、又は単なる情報としての記述であるかを明確に区別しなければならない。

要求事項の文章の末尾は、その意味の区別によって、表3のようにする。 (以上 JISZ8301:2000 7. d) )

JIS Z 8301:2000 表3 要求事項の文章の末尾

意味の区別末尾に置く語句備考国際規格での対応英語
指示又は要求・・・(し)なければらならない。, ・・・する。, ・・・とする。, ・・・による。規格に適合するためには、厳密にこれに従い、これから外れることを認めない。shall 同類: is to・・・, is required to・・・, it is required that・・・, has to・・・, only ・・・ is permitted, it is necessary・・・
禁止・・・(し)てはならない。, ・・・(し)ない。shall not 同類: it is not allowed [permitted] [acceptable] [permissible]・・・, is required to be not・・・, is required that・・・be not, is not be・・・
推奨・・・することが望ましい。, ・・・するのがよい。このほかでもよいが、これが特に適しているとして示す。又はこれが好ましいが、必要条件とはしない。should 同類: it is recommended that・・・, ought to・・・
緩い禁止・・・しないほうがよい。これは好ましくないが、必ずしも禁止しない。should not 同類: it is recommended that・・・not, ought not to・・・
許容・・・(し)てもよい。, ・・・差し支えない。規格の立場に立って、これを許すことを示す。may 同類: is permitted, is allowed, is permissible
不必要・・・する必要がない。, ・・・しなくてもよい。need not 同類: it is not required that・・・, no・・・is required

ISO/IEC の助動詞

[44] ISO/IEC 国際標準で使う助動詞は、 ISO/IEC Directives で規定されています。

[45] 次の助動詞があります >>43

メモ

[42] RFC 2119 助動詞は、注意して利用するべきもので、特に、 相互運用性にほんとうに必要な場合や、有害な可能性のある行為を制限する場合にのみ用いなければならないとされています >>41。 とりわけ、相互運用性のために必要でない限り特定の実装法を要求するために使ってはいけないとされています >>41

[16] XSPF Version 1 <http://xspf.org/xspf-v1.html#rfc.section.2.3.2.p.1>

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document MUST NOT be interpreted as described in [RFC2119]. In this document these should be interpreted to mean that something shouted is important. XSPF is not a standards track document, it is an ad-hoc project by a group of individuals. Developers may, however, find that [RFC2119] is a useful source anyway.

ワロスwwwwwwww (名無しさん 2006-08-21 12:37:11 +00:00)

[26] 一歩先のWeb標準 ♯1 | Webデザイナー・クリエイター > アイデアノート | withD (2007-04-28 11:35:15 +09:00 版) <http://wd.dsp.co.jp/web/idea/2159.html>

RFC 2119 の用語を使っているかのように見えるが、 実のところそうではない。

最初の「必須レベル」は、DTD(XHTML&#8482; 1.1 - Second Editionから、XML Schemaという選択肢も加わりました)によって明示的に文法が定義されていますので、プログラムを使った文法の検証(validate)が可能です。

とかかなりあやしいことが書かれている。 (名無しさん 2007-04-28 02:49:23 +00:00)

[33] RFC 6919 - Further Key Words for Use in RFCs to Indicate Requirement Levels ( ( 版)) <https://tools.ietf.org/html/rfc6919>

[46] ( 版) <http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.01.01_60/ts_103285v010101p.pdf>

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and

"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of

provisions).

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

[54] Editorial: refactor to depend on the Infra Standard (domenic著, ) <https://github.com/whatwg/html/commit/4ac633e08c2c9430853fc8322943bc2438ed36a3>

[55] Editorial: start using the Infra Standard (annevk著, ) <https://github.com/whatwg/encoding/commit/a26f76889bf393999e9caad84a3647ab09c39e09>

[56] Editorial: start using the Infra Standard (annevk著, ) <https://github.com/whatwg/fetch/commit/9ba4e78e5cb5fc1132f89d7e344cd2c2e1950c67>

[57] Editorial: leave ASCII case-insensitive to Infra (annevk著, ) <https://github.com/whatwg/html/commit/5f3f27bfdf0e0139f6cf5f22508f37710d917c00>

[58] Editorial: make use of the Infra Standard (annevk著, ) <https://github.com/whatwg/dom/commit/bb2890beed2be14d2f7633ec89e2bbb88ec7fdcd>

[59] Editorial: use the Infra Standard (annevk著, ) <https://github.com/whatwg/fullscreen/commit/06ae8faa6335bfdcc5c9d9e643c0cb797efbc9d9>

[60] RFC 7992 - HTML Format for RFCs () <https://tools.ietf.org/html/rfc7992#section-9.9>

This element marks up words like MUST and SHOULD [BCP14] with an HTML <span> element with the CSS class "bcp14".

You <span class="bcp14">MUST</span> be joking.

[61] これ MUST の利用例としておかしいだろ・・・

[62] Editorial: avoid "must", "should" etc. in notes (zcorpan著, ) <https://github.com/whatwg/html/commit/fb7f7676f625a2ce43efbccc97f356d4811972b8>

[63] Clarify that the conformance section is widely applicable (annevk著, ) <https://github.com/whatwg/infra/commit/fc952b8110467bd4357cf9d3ce97d430117918ee>

[64] Editorial: fix usage of RFC 2119 terms in non-normative notes (domenic著, ) <https://github.com/whatwg/streams/commit/39265f49c57e1303f78b33a2014fd1b51c2acfa7>

[65] Editorial: remove normative keywords from notes (annevk著, ) <https://github.com/whatwg/dom/commit/4ba35d93cff40fd3d3137ed44e803df17296a8cd>

[66] Editorial: remove "may" from statements of fact (annevk著, ) <https://github.com/whatwg/html/commit/91aff6d3c94a40742192b05e9d7964d95cdaaa0a>

[67] [css-images] Remove confusing RFC 2119 MUST from sentence to resolve … (LeaVerou著, ) <https://github.com/w3c/csswg-drafts/commit/33ec302371a0a7b5422de682c2a259fb5252766a>

[68] Editorial: avoid normative keywords in notes (annevk著, ) <https://github.com/whatwg/notifications/commit/fb423c7e3c5e91ff33b11cb79eaaf6370246cff1>

[69] Meta: use allow-2119 to silence Bikeshed (annevk著, ) <https://github.com/whatwg/infra/commit/534146eccfd17f65118d314b714655b62533971f>

[75] Suggest alternate keywords for non-normative content (tobie著, ) <https://github.com/whatwg/infra/commit/c9cf34165839b9a43dc0e85e5266351ef07497a5>

[76] Editorial: add note about keyword suggestion for non-normative content by tobie · Pull Request #151 · whatwg/infra () <https://github.com/whatwg/infra/pull/151>

[77] RFC 7692 - Compression Extensions for WebSocket () <https://tools.ietf.org/html/rfc7692#section-2>

[78] RFC 7322 - rfc Style Guide () <https://tools.ietf.org/html/rfc7322#section-4.8.2>

[79] Editorial: Fix “should” in input/textarea domintro (sideshowbarker著, ) <https://github.com/whatwg/html/commit/a1c7bf04c48117242dc67ec3eecc8960951c25c0>

[80] Editorial: Fix “should” in input/textarea domintro by sideshowbarker · Pull Request #3168 · whatwg/html () <https://github.com/whatwg/html/pull/3168>

[81] Fix MUST/should incosistency (estark37著, ) <https://github.com/w3c/webappsec-referrer-policy/commit/455b22cbd48aac776da73cba0688a3b3143d827c>

[82] RFC2119 Styles · Issue #126 · w3c/tr-design () <https://github.com/w3c/tr-design/issues/126>

[83] Readability of RFC 2119 terms · Issue #1380 · w3c/respec () <https://github.com/w3c/respec/issues/1380>

[84] Meta: use new WHATWG boilerplate and license (domenic著, ) <https://github.com/whatwg/compat/commit/f337512db215d4871c4035bd96aed6abd4721ffc>

[85] Editorial: avoid normative keywords in domintro block (annevk著, ) <https://github.com/whatwg/fetch/commit/78a8dcd9de92a34e1f16e9728784b77a033a654d>

[86] Editorial: avoid normative keywords in domintro block by annevk · Pull Request #734 · whatwg/fetch () <https://github.com/whatwg/fetch/pull/734>