W3C 仕様の共通部分の日本語訳

このページは、 W3C による一部の仕様に共通する定型的な記述の日本語訳です。 このページの目的は、このページを参照する 日本語訳ページ のデータ量の節減と伴に，それらの記述を繰り返し読まずに済ませられる様に 1 カ所に集約することです。

この文書の位置付け

【 以下において、 ED, WD, CR, PR, REC が付与された段落は、順に，仕様の策定段階が次に該当するもののみに適用されることを意味する 】：

  • ED = 編集者草案（ Editors’ Draft ）
  • WD = 作業草案（ Working Draft ）
  • CR = 勧告候補（ Candidate Recommendation ）
  • PR = 勧告案（ Proposed Recommendation ）
  • REC = 勧告（ Recommendation ）

以下の記述は、個々の仕様とは多少異なる部分もあるかもしれない。 正確な詳細は、各仕様の原文にあたられたし（仕様のバージョンごとに変わったり、発行年代に応じて，該当する全仕様を通じて変わることもあるかもしれない）。

この節では、発行時点におけるこの文書の位置付けについて述べます。他の文書がこの文書に取って代わる可能性があります。W3C の現在の発行リストとこの文書の最新の状態は https://www.w3.org/TR/ W3C technical reports index にて見られます。 This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

ED, WD, CR, PR： この文書は、 W3C 勧告になることを意図して X Working Group により発行されました。 This document was published by the {X} Working Group as an Editors Draft. This document is intended to become a W3C Recommendation.

【 どの Working Group 等かは、仕様ごとに異なる。 】

ED, WD： これは進行中の作業であり，予告なしに変更されることがあります。 This is a work in progress and may change without any notices.

ED, WD： Working Group は、実装からのベンダ接頭辞の除去を推奨する前に，実装から経験を得ることを意図しています。 The Working Group intends to gain implementation experience before recommending that implementations remove their vendor prefixes.

この仕様に対するフィードバックとコメントを歓迎します。 Feedback and comments on this specification are welcome, please send them to {X}.

【 コメントの宛先とされるメーリングリスト等は、仕様ごとに異なる。 冒頭の “仕様メターデータ” 内に記されることが多いが、正確な詳細は原文にあたられたし。 】

ED, WD： 実装者は、この仕様が安定的なものではないことに留意すべきです。 議論に加わっていない実装者は、仕様が互換性のない形に変更されていく状況に直面するかもしれません。 この仕様が最終的に勧告案に達する前に，この仕様の実装に関心のあるベンダは、前述のメーリングリストに加入して議論に加わるべきです。 Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

Working Group の実装報告もご覧ください。 Please see the Working Group's implementation report.

【 もしあれば。 冒頭の “仕様メターデータ” 内に記されることが多い。 】

この文書に対する変更点は、 X にて追跡できます。 Changes to this document may be tracked at X.

【 もしあれば。 X の部分は仕様ごとに異なる（ github.com URL など）。 冒頭の “仕様メターデータ” 内の “バージョン履歴”, “commit hitory” などに記されることが多い。 】

CR： W3C は安定的な文書と考えられ、開発者コミュニティによる実装が奨励されるものとして、 勧告候補 を発行します。 W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community.

CR： この文書が勧告案に昇格するための判定基準は、この仕様のすべての特色機能を実装し, Working Group により開発されるテスト一式に定められる試験に通過する， 少なくとも２つ以上の，独立で相互運用可能なユーザエージェントが存在することです。 The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implement all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group.

WD, CR, PR： この文書の発行は W3C Membership による承認を意味するものではありません。 この文書は草稿であり、いつでも，更新あるいは他の文書により置換／廃止される可能性があります。 この文書を進行中の作業でないものとして引用する事は不適切になります。 Publication as a { Working Draft, Candidate Recommendation, Proposed Recommendation } does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

REC： この文書は W3C メンバ, ソフトウェア開発者達, W3C グループや関心を持つ団体から考査され、ディレクターにより W3C 勧告として承認されたものです。 これは安定的な文書であり、他の文書にて，規範として利用したり引用することができます。 勧告を発行することにおける W3C の役割は、仕様への注目を集め，広範への配備を促す所にあります。 これは Web の相互運用性と機能性を高めます。 This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

この文書は W3C Patent Policy に従事するグループにより制作されました。 W3C はグループの成果物に関連して public list of any patent disclosures† を保守しています。 そのページには特許開示の手引きも含まれます。 特許に関する実際的知識を持ち、そこに Essential Claim(s) が含まれていると主張する者は W3C Patent Policy 第 6 節 に従って情報を開示しなければなりません。 This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

【† public list of any patent disclosures のリンク先は仕様ごとに異なる。 詳細は原文にあたられたし。 】

この文書は W3C Process Document の下で統括されています。 This document is governed by the {20XX-XX-XX} W3C Process Document.

リスク下（ at-risk ） とは， W3C による標準化過程の技術用語であり、必ずしも［ 当該の特色機能が，取下げられる／延期される危機にある ］ことを含意するわけではない。 それは、 Working Group が，［ その特色機能は、適時に相互運用可能に実装されるのは難しいかもしれない ］と予見していて、仕様を勧告案の段階へ進める際に必要とされるなら，その特色機能を［ それを除いた新たな勧告候補を発行することなく，取下げれる ］ものと，定めていることを意味する。 “At-risk” is a W3C Process term-of-art, and does not necessarily imply that the feature is in danger of being dropped or delayed. It means that the WG believes the feature may have difficulty being interoperably implemented in a timely manner, and marking it as such allows the WG to drop the feature if necessary when transitioning to the Proposed Rec stage, without having to publish a new Candidate Rec without the feature first.

適合性の要件

明示的に規範的でないもの（ “参考” ）と記された節に加え, この仕様におけるすべての図式, 例, 注記は規範的ではない。 他のすべては規範的である。 All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

この文書の規範的な内容におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、 [RFC2119] に則って解釈されるものとする。 可読性のため、この仕様では，これらの語が大文字化されて出現することはない。 【 これらが日本語訳にてどう表記されるかについては、 RFC 2119 が規定する句に利用される対訳 を参照されたし。 】 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. For readability, these words do not appear in all uppercase letters in this specification.

この仕様の中の，語 “例” を伴う用例や, 次の様にスタイル付けされて規範的なテキストから分離された部分は、参考である： Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

これは参考­例。 This is an example of an informative example.

この仕様の中の，先頭に語 “注記：” が置かれたものや, 次の様にスタイル付けされて規範的なテキストから分離された部分は、参考である： Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

注記： これは参考­注記。 Note, this is an informative note.

アルゴリズムの中の命令的言い回しによる要件（例えば： “頭部にあるスペース文字並びを剥ぎ取る”, “false を返してこの手続きを中止する” など）は、アルゴリズムを導入する際に利用されている RFC 2119 キーワード（上述）の意味の下で解釈されることになる。 Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

一部の適合性要件は、属性, メソッド, オブジェクトに対する要件として述べられる。 これらの要件は、利用者エージェント（ UA ）に課される要件として解釈されるものとする。 Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on user agents.

アルゴリズムまたは特定の手続きとして記される適合性の要件は、最終的な結果が等価になるのであれば, どのように実装されてもよい。（特に、この仕様で定義されるアルゴリズムは追い易くなるように記述されており, パフォーマンスは考慮されていない。） Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

この仕様の IDL 片は、 Web IDL 仕様に述べられる，適合 IDL 片に課される要件に従うものとして、解釈されなければならない。 [WebIDL] The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [Web IDL]

語法

Foo をインタフェースとするとき， “Foo インタフェースを実装するオブジェクト” の略記として、語 “Foo オブジェクト” が用いられる。 The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the more accurate "an object implementing the interface Foo".

語 "JavaScript" は、 [ECMA-262]／ [ECMASCRIPT] を指す。 ECMA-262 を指す公式の語 ECMAScript もあるが、 JavaScript の方が広く知れ渡っているので。 The term "JavaScript" is used to refer to ECMA-262, rather than the official term ECMAScript, since the term JavaScript is more widely known.

語 DOM は， Web アプリケーションのスクリプトから利用可能にされた API 群を指すが、必ずしも， DOM 仕様にて定義されている Document オブジェクトや他の Node オブジェクトの存在を含意するとは限らない。 【 例えば Web Workers の文脈下など。 】 [DOM], [DOM3Core] The term DOM is used to refer to the API set made available to scripts in Web applications, and does not necessarily imply the existence of an actual Document object or of any other Node objects as defined in the DOM specifications. [DOM]

IDL 属性は、（例えば，スクリプトから）［ その値を取得しようと試みられるとき ／ その値に新たな値をあてがおうと試みられるとき ］のふるまいを記すときは、［ “取得子は…” ／ “設定子は…” ］と表記される。 An IDL attribute is said to be getting when its value is being retrieved (e.g. by author script), and is said to be setting when a new value is assigned to it.

【 “取得子（ ...’s getter ）” は，原文では “On getting, ...” （訳すなら “被取得時” ）であるが、同じ文脈で前者の getter も利用されている（ getting の方は昔からある表記， getter は近年増えてきた表記）。 設定子（ “...’s setter” ／ “On setting, ...” ）についても同様。 web プラットフォーム全般にわたり、この 2 種類のどちらで表記しても特に違いはない／区別を要する箇所はないと見られるので、和訳では “取得子”, “設定子” の表記に統一している。 】【 IDL メソッドにおける対応する表記（ “..., when invoked, ...” ）は、 “被呼出時には…” と記される。 】