ウェブ関連仕様 日本語訳

このページは、 Web プラットフォーム関連の いくつかの仕様の日本語訳の一覧と,それらの日本語訳に共通する事項についての説明です。

これらの翻訳の正確性は保証されません。 これらの仕様の公式の文書は英語版であり、日本語訳は公式のものではありません。 ( 翻訳なので原文の英語と正確に同じ意味になることは決してありません。 また、当の仕様の策定者たちが想定している意味論を完全かつ正確に反映することも保証されません。 また、日本語は自然言語なので,誰がいつどこで読んでも同じ解釈になることも保証されません。 実際に誤りが見つかることも時折あります。 それらについては見つかり次第修正され,加えて用語の対訳や言い回しなども時折修正されるので、これらの翻訳が「完成」する日は永遠に来ません。)

一部の仕様は日々改訂され続けているので(特に WHATWG によるもの, あるいは W3C の編集者草案( Editor's Draft )†)、日本語訳は最新版と一致していないことがあります。 また、原文の更新に伴う,訳の更新の際に取り込み漏れがあるかもしれません††。 その完全性は保証されませんが、ツールを利用して不定期に検証されてはいます(多数の更新が積み重なったときなど)。 († CSS 関連仕様の編集者草案は、自動的に毎日更新されるようになったらしく,原文ページの日付は参考にならなくなっている。 この一覧ページに記載されている日付が実質的な内容の更新日になる ) ( †† RFC 文書, W3C 勧告については、原文の更新は無いので,和訳に埋め込みの原文との差分は検査済み。 )

ほとんどのページは、見出しなどを除く主な内容すべてがスクリプトにより生成されているので、Jacascript (の有効化)は必須ですこの背景色のものだけそうでない)。 Jacascript / CSS / DOM の対応が古いブラウザでは、表示が崩れたり,一部の機能が働かないかもしれません (古過ぎるブラウザ( IE 8 など)では表示すらされないでしょう) 。 SVG 画像や HTML5 の新タグなども( section, nav, aside など)利用されています。

日本語訳ページ一覧

各ページ共通の機能

本文ダブルクリック
当該箇所の原文を表示。
ページ左下隅のボタン
  • 目次のサイドメニュー化切替(アクセスキー A
  • (用語やインタフェースメンバなどの)索引を表示(アクセスキー S
  • 原文の全表示切替(アクセスキー Z
  • 語彙の対訳切替(アクセスキー X
見出し/定義項目† のクリック

次が含まれたパネルが表示される:

  1. その項目自身を指すリンク††
  2. 原文仕様の中の,対応する同じ項目を指すリンク( “原文” )†††
  3. ページ内の,その項目を指しているリンク一覧

パネル表示中は、左右矢印キーにより,これらのリンク先(“原文” を除く)を巡回できる。

† id が付与された項目 — 具体的には、 章/節の見出し, 定義用語, インタフェースのメンバ定義, 定義リストの見出し, 参照文献の見出し, CSS の各種プロパティやその値, 値型, 等々。 †† リンクテキストには、章/節 の見出しについては その原文,他の場合は その項目の id が示される。 ††† 和訳のみに id が付与されている項目については示されない。 また、自動処理の都合などから、原文と異なる id が付与されている項目もあるが、その場合でもリンクは元の id を指すようにしている(逆に,和訳ページが元の id でアクセスされた場合も同様)。

対訳切替など,一部機能は省略されているページもあります。

各ページ共通の表記規約

以下に述べる表記規約は原則であり,ページ間で多少異なることもあります。

スタイル

リンクのスタイルは次の3種:

英文仕様を指すリンクの一部では,マウスを重ねたとき/フォーカスをあてたときに、リンク先文書の【日本語訳】へのリンクも追加表示されます(日本語訳はバージョンが異なっていたり,部分訳の場合もあります)。

その他のスタイルは、原文のそれを残しているものもあれば,全く違えているものあります。 例えばマージンや行間を日本語に適したスタイルに変えたり、各種 仕様間の一貫性をとるため,別のスタイルに置換するなど。

マークアップ

基本的には,原文に即する様にしてありますが、次に挙げる理由から,使用タグやマークアップ構造を変更している部分もあります:

  • タグ階層の簡略化(スタイル目的のタグを除去するなど)。
  • より適切なタグの利用(後方互換性はある程度 犠牲にして)。
  • 他の仕様の和訳との一貫性をとる。
  • 重複する記述を一箇所に集約する。
  • 長文などの,全体的な関係構造を見通しよくするための、箇条書きの導入や階層構造の細分化。
  • 日本語と英語の資質/約束事の違いに由来するもの — 例えば:

    • 順序を入れ替えないと,見通しが悪くなる/記述が冗長になる場合。
    • 日本語には総称(複数形)と単数形の区別がなく冠詞もないので、個々のインスタンスを指すため、 対象 ( “対象” は,ある特定のインスタンスを指す名前)のようなマークアップ( <var> タグが利用される)は多用される。
    • 日本語は英語より語順が自由である反面,多義的になり易いので、階層化などを用いて一義化することもある。
  • 和訳固有の表記規約や自動処理の都合。
  • 原文を補完したり, 定義の依存関係を明確化するための,リンクの追加など。

これらが翻訳結果の構成に大きく反映され、見かけ上,原文と乖離する場合もときどきあります。

約物,記号類

曖昧さや多義性を抑制し,視認性も向上させる目的で、句読点や記号,括弧類その他の約物は積極的に利用されています。 これらは、仕様が対象にしている分野に関する知識や意味論に通じていない状態でも,文脈から推定する労力を軽減し, 内容を正確に読み取り易くするためのものであり†、文法的な厳密さ(互いに無矛盾かつ, 解釈が常に機械的に一意的に定まる,等)を備えているわけでも, 適用し得る所には常に利用されているわけでも, 全ページで完全に統一されているわけでもありません:

(† また,訳者の理解度/翻訳意図をより鮮明に表すものでもあるので、解釈/翻訳に誤りがあれば,それをより鮮明に示すことになる — 例えば,角括弧の用法: 英文 “only in X or Y” ( X, Y は何かの集合) の解釈は、文脈に依存して, “[ X 内のみ ]または[ Y 内のみ ]” が意図されている場合もあれば, “[ [ X または Y (和集合)]内のみ ]” が意図されている場合もある )

記号説明/用法(原則)
隅付き括弧 , 訳者による【注釈/原文の補完】
全角 丸括弧 , 後述の全角ダッシュとは対照的に、主に,補助的な説明や例示(例えば,“CSS( Cascading Style Sheet )” のように)を与えるために利用される。
半角 丸括弧 (, ) 主に,平文の中で、アルゴリズムの入力引数, あるいは数式を括るときに利用される。 (全角と見た目の区別が付きにくいが、文脈から容易に判別できるであろう。)
全角 角括弧 , 修飾や条件などの対象範囲の明示的な括り。 例えば、[[列挙された多数の語句]や長い語句]を文の中で一体として扱うとき,あるいは 読点の結合順位(後述)だけでは不足する場合など(例えばこの文では、内側の [, ]により “列挙された” が “長い語句” にかからないようにした上で,“一体として扱われる” 対象を明確化するために外側の [, ]で括っている)。 特に必要がない所でも,同じパターンが繰り返されるときは、パターンを強調するために利用されることがある。 また、長文の構造を読み取り易くする際にも利用される。 ( これは、話し言葉のように一息に話すことにより,ひとまとまりを表現するような柔軟性を、多少なりとも書き言葉に付与するためのものでもある。 また、書き言葉であるからして,発音できない各種記号を使わない手はないであろう — 語句の順序を 論理的な流れを追い易いものに保ちつつ,曖昧さを排除するためにも。 厳密さを追求するなら、記号に頼らず,あらゆる関係構造をマークアップに落とし込んだ上で, CSS で呈示に反映させるのが理想であろうが。 )
全角コロン "" コロンの前の語句に,後続の文やブロックでその説明や定義を与える(特に,説明が長くなる場合)。
句点 "" 句点は "。" に統一。
全角読点 "",
全角カンマ "",
半角カンマ ","
結合度の低い順に,左の3種類が読点として利用される。 結合度が全角読点の一種類で済む場合でも、連続性が強い所では,カンマが用いられる。 また,半角カンマ(+半角スペース)は、文脈の中で等格な[ 語句/キーワード ]を列挙する際に特に用いられる。 (これらは,実質的に “, ” の略記と見なせることが多い。)
全角ダッシュ "" (1) 長めの語句の挿入(丸括弧が補助的な説明を挿入するのとは対照的に,規定としての語句を挿入するときなど — 2 個の emダッシュで括られる)、あるいは, (2) ダッシュの両側の二文の関連性を明示するときに(句点で区切る代わりに)用いられる。 U+2015 ( HORIZONTAL BAR ) ではなく, U+2014 ( EM DASH )。
全角スラッシュ ""
  • 並立的な列挙の明示。 (例えば, “a/b は C である” は、 “a は C であり, b も C である” の省略記法。あるいは, “ x = y/z ならば P である” は、 “x = y ならば P であり,また, x = z ならば P である” の省略記法。) (別の言い方をするなら、 “a/b” は[ a, b ]の総称を表す。 すなわち、ある用語 T が “a または b である” と定義されているならば、 “a/b” は “T” と記されても同じことになる。)
  • 対応関係の明示(例えば, “a/b/c は A/B/C である” は、 “a は A であり, b は B であり, c は C である” の省略記法( “a は B である” 等は除外される))。
  • 半角カンマの代わりに利用される,等格な語句の区切り(視認性の向上,あるいは 語句に読点が含まれているときなど)。
半角スペース “小さな” 区切り。
  • [英単語, キーワード, 埋め込みコード類]等と 地の文との区切り
  • 読点の結合度の順位数が足りない場合の補助
  • 読点の挿入が不適切な所での、文節の区切り(例えば: “〜の間 存続する” のように漢字が連続する地点, あるいは “〜により近づく” のような多義的な解釈( “〜により,近づく” / “〜に,より近づく”)が生じる所での一義化)
  • より連続性が重視される所での,読点の代わり
  • 同じパターンが繰り返される場合の,読点の省略形
  • 連続する熟語/外来語が長くなるときの区切り(例えば
    “リクエスト ヘッダフィールド” など — このような場合、意味構造をなるべく保つため,“ヘッダ” と “フィールド” の合間にはスペースは挟まれない)
二重引用符:
(曲線型)
(半角) ""
“曲線型” の方は,通常の引用符(説明のための,比喩的/概念的な記述など)。 "半角" の方は,仕様が規定するリテラルや記号類, 例示コード類の括りなど,意味よりも文字列そのものの同一性/忠実さが重視される所で利用される。

これらの記号を多用する理由は、(前提として多義的に解釈されては困る)仕様書の一般的な傾向として: 初見の用語の比率が高い / あらゆる事例に対応するため 条件など様々な修飾が多用される(したがって文の構造も複雑になる) / 同じ理由で抽象度の高い用語が多用される傾向にある / 説明などの補助的な文章も最小限に抑えられている / “ストーリー” がない, などの理由から、文脈から意味構造を一義的に決定するのが比較的 難しくなるので — 例えば「黒い目のきれいな女の子

RFC 2119 が規定する句に利用される対訳

どの和訳にも,次に挙げる対訳が利用されています:

MUST ( MUST NOT ) 〜しなければ(〜しては)ならない (a)
SHALL ( SHALL NOT ) (*1) 〜する(〜しない)ものとする (a)
REQUIRED 要求される (*2) (a)
SHOULD ( SHOULD NOT ) 〜するべきである(でない)(*3) (b)
RECOMMENDED 推奨される (b)
MAY 〜してもよい (c)
OPTIONAL (*4) 任意選択オプション / “(省略可)” (c)

表の右端列の: (a) は絶対的 要件, (b) は特別な理由が無い限り守るべき要件, (c) は字義どおり任意に選択できる ことを意味する。 これらの対象にされる主体には、主に: 実装者( UA やサーバ) / ページ作者( Web 内容) / 仕様 策定者(その仕様に依拠する他の仕様) などがある。

原則として、上に挙げた以外の対訳は利用されていない筈です(*5)。 逆に、他の句に上に挙げた対訳を利用することも避けています。 ただし,小文字の “must” 等は、これらの語に対する大文字表記(またはマークアップ)が[ 省略されている仕様 / 省略されていない仕様で RFC 2119 の意味の下で用いられていると考えて差し支えない所 ]では、マークアップを施さないまま,同じ対訳にされています。

  • (*1) SHALL が用いられることは滅多にない。
  • (*2) 対して,“必要になる”, “要する” などは、必然的に要件とされる(選択の余地がない/外部から要求されている)ことを表すときに用いられる。 (この種の句に “必要” という語を利用しない理由は、 “need”, “necessary”, “have to” などの対訳に必要になるからである。)
  • (*3) ごく少数だが, “ought to” の対訳に(客観性を表す)受動的な表現 “〜されるべき” が用いられることがある。
  • (*4) 仕様が規定する[ アルゴリズム / API メソッド ]の省略可能な引数にも語 “optional”, あるいは “optionally” がよく用いられる。 これらについては、通例, “オプションの〜” または引数の直後に丸括弧 付きで “〜(省略可)” と記される。 これは、[ そのアルゴリズムを利用する(当の, または他の)仕様 / その API メソッドを利用する作者 ]にとっての “任意選択” を意味することになる。
  • (*5) 日本語表現の都合により,同じ要件レベルを表す等価な句に変えることはたまにある。
  • (*5) (特に小文字の) “may” に関しては、単に可能性を表す場合も多く、“〜することがある” 等の訳が適切になる場合 / 両義的に受け取れる場合も多々ある( “might” が実質的に “MAY” の意味に受け取れる場合もある)。 可能性の “can” や “may” は、実際には,仕様の読者(実装者/ページ作者/仕様策定者)に応じて訳を違えるべき場合が多く、あらゆる読者に対応するためには, “… 実装者にとっては 〜 され得る, または ページ作者にとっては 〜 できる” のように記さなければならないことになるが、それではあまりに煩雑になるので,そこまで対処してはいない。

共通の慣用表現

多くの仕様では,以下に挙げるような慣用句が用いられています(括弧内は原文の表現):

O には P が結び付けられる( O has an associated P )”
〜を持つ” / “〜の” / “属する
ある分類(あるいはクラス, 型, 等々) C が定義されていて、各 C オブジェクト( C に分類される各インスタンス = “各個体”) O に対し, “O には P (という名前が表す対象)が結び付けられる” という句は、仕様が定める概念的なモデルにおいて, C オブジェクトの集合から P がとり得る値の集合への,名前 P の対応関係が存在する( “O は名前 P の対象を持つ” ), そのように規定される、と解釈すればよいであろう。 この P の値を参照するときは、 “O に結び付けられている P”, あるいは 単に “OP” とも記される。
“結び付け” による対応関係は、しばしば,一部の C オブジェクトに対しては定義されないものと規定される場合もある( “OP を持たない” )。 そのような所では、 “結び付けられ得る” という句が用いられる(あるいは、 “持たない” ときは, P は null 値をとるものと定義されることも多い)。

仕様には明文化されないことも多いが,多くの場合、この結び付けは 暗黙的に “専属的” な関係を含意する。 一方で,該当しない場合もあり、この区別は 文脈から判断する必要がある:

  • P が数値や真偽値のような primitive 値をとる場合、通例的に個別のインスタンスが作成されるので,自然に専属的になる。 また、文字列のような(通例的に)変異不可( immutable )の値をとる場合も同様に専属的と見なせる。
  • P がオブジェクト値( p とする)をとる場合:
    • 結び付けによる関係が専属的であれば、 p から それを結び付けている O が一意に定まり、また、 p に変更が加えられても,他の C オブジェクトには影響しないことになる。
    • 専属的でない場合(複数の C オブジェクトが同じ p を共有し得る)、そのことを明らかにする目的で,和訳では “Op属する” という句を用いることもある( “属する” という語が意味論的にも相応しければ)。 この場合、 O に対応する p を指すときは, “O が属する P ” という句も用いられる。 また、 p を結び付けている C オブジェクトの集合を指すときは、 “p に属する O” という句も用いられる。
“紐付け‎” という語もよく見受けられるが,明示的に 「“associated” の対訳は “紐付け” ‎」 と述べている文書は見当たらない(ひょっとしたら,その “紐付け” は “link” / “relation” / “connect” / “bind” かもしれない)。
“初期化される( is initialized to )”
“初期化時の値( value it was initialized to )”
“初期化される” という句は,多くの場合、特に IDL 属性に対する,内部(仕様が定める処理モデル)からの値の設定を記す際に用いられている(必ずしも, “一度限り” を意味するわけではないことに注意 ( すなわち、何か値が設定されているとしても,現在の文脈からは その値が未知である変数の値を、既知の値に設定する )。 仕様が定める概念的なモデルと, IDL インタフェースを通して外部に公開されるふるまいとの対応関係を明示的に記すための語、と解釈すればよいであろう。 “初期化時の値” は,この初期化により設定された値を指す — すなわち,初期化された値が,スクリプトなど外部から影響されないことを明示する(あるいは次項の “被設定時” と区別する)ための語と解釈すればよいであろう(読み取り専用の属性に対し用いられることが多い)。
“被取得時( on getting )”
“被設定時( on setting )”
特に IDL 属性に対し,外部(スクリプト側)から “値の取得/設定アクセスが試みられたとき” の略語として用いられる。 主に IDL 属性のふるまいを記述する際に利用される。
同じ意味で “取得子( getter )”/ “設定子( setter )” という語が利用されることもある( JavaScript 言語の影響からか、 2015 年頃から,こちらの語が好まれる傾向が高くなっている)。
“新たな (を作成する, を返す …等々)( [ create / return ] a new )”
” に記された種別のオブジェクト — IDL インタフェースを実装するオブジェクト, または,仕様が規定する概念的なオブジェクト — のインスタンスを新たに作成する(構築する)ことを意味する(すなわち,既存のどのオブジェクトとも “同じでない” )。
null
null は、一般的には,意味のある値を持たないことを意味する特別な定数を表す(値 null をとる 2 つの変数は,同じと見なされる)が、 IDL nullable 型和訳) がとり得る特別な値 null を指すことも多い。
ε
存在しないことを表現する特別な定数( null と同様、値 ε をとる 2 つの変数は,同じと見なされる)。 この記号は和訳に特有であり、アルゴリズムや定義の記述を形式化して,簡潔に述べるために導入している — 仕様にてこの意味を表す値として明示的に null が利用される場合もあるが、そうでない場合も多々あるので。
一部の仕様の和訳では、仕様にて null で表現されている場合でも, IDL null 値との違いを明確化するために ε を利用している。
true, false
一般的には,真偽値を意味する特別な定数を表すが、 IDL boolean 型和訳) がとり得る値 true, false を指すことも多い。
“〜 フラグ( flag )”
“〜 モード( mode )”
“〜フラグ” という名前は、主にアルゴリズムの制御目的に利用される, “オン”, “オフ” 2種類の状態をとり得る変数/プロパティに特に用いられる。 3種以上の値をとり得る変数に,この名称が用いられることはなく、その種の制御変数は,通例 “〜モード” と命名される。 和訳におけるフラグ値は、各種 仕様間の統一を図るため,多くの場合 “ON”/“OFF” と記しているが、原文の表記をそのまま用いる場合もある(原文では[ set/unset ], [ set/clear ], [ true/false ] 等々と記されることが多いが、より明示的な意味を持つ名前にされていることもあるので)。
アルゴリズムの入力パラメタとして与えられるフラグは、そのアルゴリズムを呼び出す際に省略され得る。 その場合のフラグの値は暗黙的に “オフ” をとる。 (英語的感覚では、フラグ値 OFF ( unset )と上述の ε は,同義と考えられる。)
オブジェクトに結び付けられているフラグは、通例,オフを初期値にとるものと規定される。 そのようなフラグは、 “オブジェクトは X である” という意味を, “X フラグ は ON ” という形に形式化して反映している場合が多い。
“段( step )”
“手続き( steps )”
“段” は、手続き/アルゴリズムの記述を構成する 1 個の ブロックを指す。 具体的には、手続きのマークアップ表現における,順序リスト( OL 要素)の中のリスト項目( LI 要素)で表現される 1 個のブロック(入れ子階層の末端のブロックに限らず)。 例えば “前段” は、その “前段” と記されたブロックと同じ階層レベルの,直前のブロックを指す。
“下位手続き( substeps )”
ある手続きの記述の中で、入れ子に記述され,独立な実行単位と見なせる手続きを指す( “次の下位手続きを実行する…”, 等々)。 一般に,下位手続きは、上位の手続きで利用されている変数や引数をそのまま参照するが,実行制御の視野は 当の下位手続きに絞られる — 特に,下位手続きの中での RETURN (次節を見よ)は、上位の手続きではなく,当の下位手続きを終了させる。 ( JavaScript のクロージャ関数(関数内に定義される関数)に似る。)
この語は、上位の手続きが呼び出した 非同期に実行される演算に対し,その結果を取り扱う手続きを指すときに利用されることも多い。
注記: 表記法(次節)の都合から、和訳では,原文の “substeps” すべてを,そのまま “下位手続き” と訳してはない。 実行制御の視野を変えたくない/変える必要のない所では、訳から外している (単に “次を実行する…”, 等々)。 逆に、手続きの中の一連の段を下位手続きとして記述し直すこともたまにある — 実行制御の視野を絞った方が簡潔に記述できる場合など。
文脈オブジェクトcontext object )”
これ°
論の対象のインタフェースメンバ(メソッド/属性取得子/属性設定子)が呼び出されているオブジェクト自身(その種のメンバを定義しているインタフェースを実装している,ある特定のインスタンス)を指す。 通常、そのメンバのふるまいを規定するアルゴリズムの中で用いられる。 API 記述の比重が高い仕様では、頻出するので,より簡素に太字で “これ°” とも記される。
フック( hook )
拡張性のために、当の仕様が,自身が規定する手続きのある段を[ 外部(他の仕様など)から供される処理を( callback 関数のように)実行する場 ]として,提供するもの。 (参考

アルゴリズムに共通して用いられる表記法

仕様の中のアルゴリズムは、順序付きリストの入れ子階層によるマークアップにより,一般的なプログラミング言語と同様の実行順序/制御構造が表現されています。

(特にアルゴリズムが占める比率が高い,)一部の仕様の和訳では、アルゴリズムの中の定型的な記述を簡明に, かつ一貫させるため、いくつかの記号を導入しています(個別の仕様ごとに,追加の記号が導入されることもあります):

記法意味
これ° 上述の 文脈オブジェクト の略記。
ε 存在しないことを表現する特別な定数( 詳細 )。
変数 :← 新たな 変数 を導入した上で,その値を与えられた に初期化することを表す(原文 “Let 変数 be …” )。
変数 既存の 変数 (またはプロパティ/属性)への の代入/設定を表す(原文 “Set 変数 to …” )。 ( :← や ← のような記法を用いる理由の一つは、代入(もしくは定義)や設定の日本語表現には “A を B とする”, “A を B に設定する”, “A が B になる”, “A を B にする”, “A は B とする”, …等々,多種多様な言い回しがあり、文脈, あるいは A, B の役割や定義に依存して,どちらが代入/設定される側になるかの解釈も変わり得るため,誤解の余地も生じ易い/文脈を汲み取る労力を要するので。 もちろん,何らかの表現を一貫して用いることは考えられるが、訳者自身もしばしば,どの表現に統一されているのか忘れることがあるので。 要するに翻訳の手間を省くことも目的の一つにある。 )
変数 += n,
変数 −= n
変数 に対する増減操作(+= は加算, −= は減算, n はその量)を表す。
+, , ×, ÷ (数式の文脈の下で)数値の加減乗除算(あるいは正負符号)を表す。 (負符号 "" は Unicode MINUS SIGN 。 除算は 原文では通例 "/" で記されるが、他の区切り記号にも多用されるので,和訳ではなるべく "÷" を利用している。)
>, , <, (真偽条件の文脈の下で)数値の比較を表す。
A B,
A B
AB が同じであることを表す(原文 “A is B” †)。 の否定を表す。 仕様には明文化されていないことも多いが,同じであることの定義は、比較対象が属する型に依存する — 通例的には、比較対象が: オブジェクトの場合は 同一のインスタンスであるとき / 数値などの primitive 値の場合は 値が等しいとき / いくつかの値の組のような複合値の場合は それぞれの対応する成分が同じであるとき,同じとされる。 († “A is a B” は、通例 “A は B である” と訳される。 )
A A がリストや集合であるとき、これは,実際には “A の要素数 ゼロ” の略記である。 についても同様。 “空” の代わりに “∅” が用いられることもある。
AB 値の範囲を表す( A, B も含まれる — ただし,A > B の場合の範囲は空集合になる)。
{ } 括弧内に挙げられた対象の集合を表す。
e S,
e S
e の集合 S への所属( )を表す。 はその否定を表す。 例えば e { a, b, c, … } は、 e が右辺に列挙されたいずれかの項と同じ( )であることを表す。
A 注釈記号 B 注釈記号 が付いた比較は、その記号の定義に基づいて解釈される(例えば “大小無視” は、文字大小無視に基づく文字列の比較を表すなど)。 記号の意味は、個々の仕様の中で定義される。 の代わりに , なども利用される — その論理は 注釈記号 に定義される同値関係に基づく。
ON, OFF フラグの状態値を表す。 上述のフラグの項を見よ。
IF 条件ブロック 条件 が成立するときに限り,ブロックの内容を実行することを表す。
ELSE [ IF 条件] :ブロック 直前に現れている, 同じ階層レベルの[ IF および それに後続する ELSE IF ]に与えられた どの条件も,それが評価された時点で満たされなかったときに限り(すなわち,それらのどの ブロック も実行されなかったときに限り)、加えて, IF 条件 が与えられている場合は その条件も成立するときに限り、 ブロックの内容を実行することを表す。 したがって, ELSE 単独で現れている場合、当の条件節の終端を表すことになる。
に応じて:
条件1
ブロック1
条件2
ブロック2
いわゆる switch 文。 に記された対象が後続の どの 条件1, 条件2, … を満たすかに応じて、対応する ブロック のみを実行する(あるいは,その記述に従う)ことを表す。 各 条件 は、多くの場合,対象がとる値/値の範囲として記される。 その場合、対象の値が[ 示された値と同じ/ 示された範囲に入る ]という条件として解釈することになる。 各 条件 による場合分けは,通例 排他的になるが、そうでなければ何らかの処理規則(例えば, “最初に該当する段を実行する” など)が付記されることになる。
WHILE 条件ブロック 条件 が成立する間,ブロック の内容を繰り返し実行することを表す。 条件 に “無条件” と記されている場合は無限に繰り返すことを表す( ブロック の中の BREAK などにより繰り返しを終える)。
( 対象 ) に対し :ブロック ” に記された[ 対象範囲に属する, あるいは条件を満たす ]ような 対象 それぞれについて,その列挙順序が明示的に指定されていれば その順序に従って、ブロック の内容を実行することを表す( “for each” )。 列挙順序が指定されていない場合、一般に,対象範囲がリストのような元々順序を備える集合の一部であれば,その順序に従う。 処理結果が列挙順序に依存しないものについては,順序が指示されないこともあるが、依存する場合は実装依存になる可能性がある。
CONTINUE 繰り返しループ( WHILE … / “ ( … )” )において、現在の反復を中断して,次の反復へ移行することを表す。
BREAK 繰り返しループから抜けて,ループブロックの次の段へ移行することを表す。
GOTO ラベル ラベル が付与された段へジャンプすることを表す。
THROW 例外名

名前 例外名例外オブジェクト† を 投出した上で,(特に並列的に実行を継続する指示が与えられていない限り)現在の手続き終了することを意味する。 例外は、例外を投出したアルゴリズムを呼び出したアルゴリズムにも伝播する。 すなわち、呼び出した側も,その例外に対する処理が特に指定されていない限り、(呼び出しが行われた所で)その例外を再投出した上で,その手続きを終了することになる。

DOMException, 単純例外Error ) いずれのオブジェクトが投出されるかは,ほとんどの場合,名前から判明するので、日本語訳では、その区別を省略している(原文仕様では,区別して記されているもの( HTML 仕様など)も,そうでないものもある)。

ECMAScript 言語束縛における, “例外の投出” の具体的な処理内容は、 WebIDL 仕様に 定義されている日本語訳)。

RETURN [] をアルゴリズムの呼び出し元に返した上で,(特に並列的に実行を継続する指示が与えられていない限り)現在の手続き終了することを意味する(下位手続きの中では、上位の手続きではなく,当の下位手続きを終了させる。)。 を伴わない RETURN は、返り値が無いことを意味する。 呼び出し元のアルゴリズムにて,この返り値を指すときには、通例, “〜した結果”, “〜の返り値” と記される。
Assret条件 いわゆる表明。 条件 で表現される暗黙的な不変則を明示的に示して,アルゴリズムの明確化を図るものであり、アルゴリズムの意味論に要件を追加するものではない。 アルゴリズムの入力が満たしているはずの条件が記されることが多い。

語彙の対訳について

日本語と英語には(特に文の構造に)大きな開きがあるので、語彙以前に,原文を論理的に等価な言い回しに変形することも よくあります — 例えば,対偶をとるなど。 (挙げていくと際限ないが,実際には、英語のすべての定冠詞(の有無, あるいは all, every, each 等々), あるいは語形変化など、およそすべて, “等価な” 言い回しに変形することになる。 双方の言語には,利用する語彙そのものに異なる視点が組み込まれているので、より適する言い回しも,必然的に異なることになる。 単語の省略法も異なるので、原文に無い語を補完したり,逆に原文の語を省略することも ときには必要になる。 )

また、英語は動詞が中心的な意味を担う場合が多く、プログラミング言語で言い換えるなら,いくつかの callback 関数を入れ子にして記述するのに近い感がある(直訳的には、 “〜することを〜することを〜することを … 〜する” のように — 5 段くらい入れ子にされることも珍しくない — そのような入れ子の動詞は、主語や目的語, あるいはその両者が省略されていることも多い(事実上、英語の方が日本語より主語や目的語の省略は多いかもしれない))。 ついでに、英語の動詞(例: serialize )は ある関数を実行すること, 動名詞 〜ing (例: serializing )は 関数のある実行インスタンス, 動詞を語源とする名詞(例: serialization )は 関数そのものの定義に対応付られるような感もある。

マークアップや自動処理などの編集上の都合が,以下の原則より優先されている箇所も中にはあります。

仕様が規定するモデルの定義をより明確化する/簡潔にするため、和訳では,明示的に定義用語とされていない語にマークアップを施したり, 新たな用語を導入することもあります。 例えば、ある語 X が,単独の個としての意味と いくつかの集合としての意味を兼ねて定義されることもよくある — 英文では, “X”, “Xs” のように単数形と複数形で自明に/慣用的に区別し得ても、和文では, “X”, “X リスト” のように,明示的に分けて定義しないと不明瞭になることがある。

カタカナ語の語尾の長音( “ー” )表記について

無くても差し支えない所は省略する方針です: カタカナ表記の役割としての,とりあえず近似的な発音で代用して記憶し易くする/原語スペルを復元し易くする 観点からは、大方,在っても無くてもさして変わらず、カタカナ語(表音文字系の言語)は本来的に,文字数に比して短く一息に読まれる方が 文章のリズムは取り易く出来ているものと考えられるので。 また、多用されている全角ダッシュ( “—” )と紛らわしくなるのも避けたいので。 ( 長音無しを基準にとれば “省略” という言い方もおかしい? 長音付きが好みの方は脳内変換で対応して下さい。 脳内変換に関して言えば、長音[ 無し → 有り ]に 補完して 読む方が,[ 有り → 無し ]に 省略して 読むよりも馴染み易いのではないだろうか? )

例えば “ティ” で終わる語の語尾の長音は、全般的に,長音の有無で意味が変わったり, 長音が省略された語の方だけ使用されない事例はごく稀と思われるので、省略しています( “プロパティ” など)。 動作の主体(動詞の変化形)を表す語尾の長音( “サーバー”, “ユーザー”, “パーサー”, “オブザーバー”, 等々)についても,大半は省略されています(仕様の中ではこの種のものが大勢を占める)。

ローカル保存

Github ページ からリポジトリをダウンロードできます。

上に挙げたページは翻訳なので二次著作物であり,その翻訳作業に関わる部分の著作権は翻訳者(連絡先)に帰属することになりますが、翻訳者はその利用について、原著作物の著作権に起因する制約を除き,次の通りと定めます: