ウェブ関連仕様 日本語訳

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

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

一部の仕様は日々改訂され続けているので(特に WHATWG による Living Standard ( “生きた標準” ), あるいは W3C による Editor's Draft (編集者草案))、日本語訳は最新版と一致していないことがあります。 また、原文の更新に伴う,訳の更新の際に取り込み漏れがあるかもしれません†。 その完全性は保証されませんが、ツールを利用して不定期に検証されてはいます(多数の更新が積み重なったときなど)。 ( † RFC 文書, W3C 勧告については、原文の更新は無いので,和訳に埋め込みの原文との差分は検査済み。 )

ほとんどのページは、タイトルを除く内容すべてがスクリプト( JavaScript )により生成されているので、 スクリプトの有効化/サポート( ES 6 ( ECMAScript 2015 )以上)は必須ですこの背景色のものだけそうでない)。 また, CSS / DOM / HTML の対応が古いブラウザでは、表示が崩れたり,一部の機能が働かないかもしれません ( 古過ぎるブラウザ(すべての IE を含む)では表示すらされないでしょう — 他のブラウザをご利用ください )

ほぼすべてのページは、仕様のメタ情報を,タイトルの下に 次のようなクリックで開閉できる details 要素で呈示しています:

この日本語訳は非公式な文書です(翻訳更新: <日付> )

ここには、当の日本語訳が元にしている原文についてや, 定型的な事項など,翻訳に関するメタ情報が記される。

  • 日本語訳の更新履歴を指すリンク(例:このページの更新履歴)も,ここに挙げられる。
  • “翻訳更新” の日付は、概ね,実質的な内容が変化した場合に限り,更新される。 マークアップの編集, 表記上の整理, 言い回しを等価に違える程度では、更新されない(が,翻訳の誤りを訂正した場合は更新される)。 また、原文の更新を反映した場合も,同様に小さな編集(マークアップや綴りの修正)や仕様メタデータのみの場合は更新されないので、原文の更新日より過去になることもある。
仕様メタデータ

ここには、原文の冒頭に記されているメタ情報が,ほぼそのまま記される。 原文やその更新履歴, メーリングリスト, テスト一式, 実装報告, その他を指す URL など。 便宜のため、原文に記されていない/他所に記されているメタデータを追加することもある。

©

ここには、原文の著作権情報が記される(が、仕様によっては,他所に記されることもある)。

索引など

ここには、仕様内に記された課題( issue ), 定義されている IDL やプロパティ, 等々を巡回するための UI が示される(多くの原文には,それらに対応する索引節があるが、和訳では省略して このような UI に代えている)。

Github リポジトリ から全ファイルを一括ダウンロードできます(冒頭にある "Clone or download" から "Download Zip" を選ぶ)。

日本語訳ページ一覧

各ページ共通の機能

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

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

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

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

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

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

各ページ共通の表記規約

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

スタイル

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

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

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

マークアップ

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

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

約物,記号類

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

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

記号 説明/用法(原則)
隅付き括弧 , 訳者による【注釈/原文の補完】
全角 丸括弧 , 後述の全角ダッシュとは対照的に、主に,補助的な説明や例を挿入するために利用される(例えば、この括弧内に記した句のように)。
半角 丸括弧 (, ) 主に,平文の中で、アルゴリズムの入力引数, あるいは数式を括るときに利用される。 (全角と見た目の区別が付きにくいが、文脈から容易に判別できるであろう。)
全角 角括弧 , 修飾や条件などの対象範囲を明確化するための括り。 例えば、[[列挙された多数の語句]や長い語句]を文の中で一体として扱うとき,あるいは 読点の結合順位(後述)だけでは不足する場合など(例えばこの文では、内側の [, ]により “列挙された” が “長い語句” にかからないようにした上で,“一体として扱われる” 対象を明確化するために外側の [, ]で括っている)。 特に必要がない所でも,同じパターンが繰り返されるときは、パターンを強調するために利用されることがある。 また、長文の構造を読み取り易くする際にも利用される。 ( これは、話し言葉のように一息に話すことにより,ひとまとまりを表現するような柔軟性を、多少なりとも書き言葉に付与するためのものでもある。 また、書き言葉であるからして,発音できない各種記号を使わない手はないであろう — 語句の順序を 論理的な流れを追い易いものに保ちつつ,曖昧さを排除するためにも。 厳密さを追求するなら、記号に頼らず,あらゆる関係構造をマークアップに落とし込んだ上で, CSS で呈示に反映させるのが理想であろうが。 )
全角コロン "" コロンの前の語句に,後続の文やブロックでその説明や定義を与える(特に,説明が長くなる場合)。
句点 "" 句点は "。" に統一。
全角読点 "",
全角カンマ "",
半角カンマ ","
結合度の低い順に,左の3種類が読点として利用される。 結合度が全角読点の一種類で済む場合でも、連続性が強い所では,カンマが用いられる。 また,半角カンマ(+半角スペース)は、文脈の中で等格な[ 語句/キーワード ]を列挙する際に特に用いられる。 (これらは,実質的に “, ” の略記と見なせることが多い。)
全角ダッシュ "" この文のように,長めの語句を挿入する所 — 丸括弧が補助的な説明を挿入するのとは対照的に,規範的な語句を挿入するときなど — では、 2 個のダッシュで括られる。 この文のように,二つの文の関連性を明示する所では、 1 個のダッシュで繋げられる — 最初の文を句点で区切る代わりに。 ( 全角ダッシュ文字には 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 ]の総称を表す(すなわち、 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 〜するものとする( UA 要件 ) / 〜しなければならない (a)
MUST NOT 〜しないものとする( UA 要件 ) / 〜してはならない (a)
SHALL / SHALL NOT MUST と同じ (*1) (a)
REQUIRED 要求される (*2) (a)
SHOULD 〜するべきである (*3) (b)
SHOULD NOT 〜するべきでない/ 〜しないべきである (b)
RECOMMENDED 推奨される (b)
MAY 〜してもよい (*4) (c)
OPTIONAL 任意選択オプション / “(省略可/省略時は〜)(*5)” (c)

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

共通の慣用表現

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

“各 O には P が結び付けられる( O has an associated P )”
〜を持つ” / “〜の” / “属する

この句には、一般に,次が含意される:

  • O は、何らかの分類(クラス, 型, 何らかの性質を満たすものの集合, 等々) — 以下 C と記す — に属する,任意の(所与の)個体(インスタンス)である。 (分類が,ある IDL インタフェース型 Foo として指示される場合、 O は “Foo オブジェクト” と称されることが多い — この場合、 CFoo インタフェースを実装するオブジェクトの集合を表すことになる。)
  • P は、何らかの分類(を表す名前)である。
  • 分類 C を成す個体の集合から分類 P を成す個体の集合への,名前 P の対応関係(写像)が存在するものと規定される( “O は、名前 P の対象を持つ” )。

より形式的に述べるなら、次のように規定されると解釈すればよいであろう:

  • C に属する任意の個体 O に対し,次の両者を満たすような個体 V がただ一つ存在する:

    • VP に属する
    • 順序対 ( O, V ) は,関係 < C, P > を満たす

    そのような V を指すときは、 “ O に結び付けられている P ”, あるいは単に “ OP ” とも記される。

“結び付け” による対応関係は、しばしば,[ C に属する一部の個体に対しては定義されない ]ものと規定される場合もある( “OP を持たない” )。 そのような所では、 “結び付けられ得る” という句が用いられる — あるいは “持たない” ことを[ P が値 null も含むようにした上で, “OP として値 null をとる” ]ことで表現する場合も多い。

仕様には明文化されないことが多いが、この結び付けは “専属的” な関係を含意することもある — すなわち, P に属する所与の個体 V に対し,関係 < C, P > を満たす C に属する個体 O は、あっても 1 つに限られる。 一方で,該当しない場合もあり、この区別は文脈から判断する必要がある。

  • 結び付けによる関係が専属的であれば、 V から それを結び付けている O が一意に定まり、 V に変更が加えられても, C に属する他の個体には影響しないことになる。
  • 専属的でない場合( C に属する複数の個体が,同じ V を共有し得る)、そのことを明らかにする目的で,和訳では “OV属する” という句で表現することもある。 この場合、 O に対応する V を指すときは, “O が属する P ” という句で表現される。 また, V を結び付けている[ C に属する個体の集合 ]を指すときは、 “V に属する O (たち)” という句も用いられる。 ( “属する” という語が意味論的に相応しくなければ、他の語を用いることもある。 )
Pprimitive 値の集合である場合、 “異なる各値ごとに 1 個しか存在し得ない” と解釈する(そう解釈すれば、統一的に扱えるので都合が良い)。 この解釈の下では、どの primitive 値も それを P 値にとる C に属するすべての個体から共有されることになり、通例, “専属的” にはなり得ない。
“結び付け” と同じ, または よく似た意味で “紐付け‎” という語も一般によく見受けられる — が、その “紐付け” は、 “link” / “relation” / “connect” / “bind” など,違う意味かもしれない。
primitive データ型
技術的な分類は,個々の人工言語ごとに様々な定義があろうが、一般概念としては,[ 値それ自体が 個を識別するものとしても働くデータ型 ]と捉えて差し支えないと見受けられる — すなわち、そのような 2 つの値 a, b があって “等しい” ならば、 a, b は “同じ(同じ個体)” と見なされる(オブジェクト的には、変異不能なオブジェクトである)。 具体的には、文字列, 真偽値, 数量的な値, 抽象的な定数など。 リスト(配列)やマップなどの複合的な型は、(基本的な型ではあるが)この捉え方においては, primitive データ型とは見なされない — これらは一般に,オブジェクトとして扱われ、異なる個体は,各成分が互いに等しくても “同じ” とされない。 ( 文字列は、文字たちが成す配列であるとして,複合型に分類される言語もあるが、 Web プラットフォームにおいては,一般に primitive データ型とされる。 配列として扱われる(変異可能な)文字列は、通例的に “バッファ” , 等々と称され,文字列と区別されることが多い。 )
“初期化される( is initialized to )”
“初期化時の値( value it was initialized to )”
“初期化される” という句は,多くの場合、特に IDL 属性に対する,内部(仕様が定める処理モデル)からの値の設定を記す際に用いられている(必ずしも, “一度限り” を意味するわけではないことに注意)。 仕様が定める概念的なモデルと, IDL インタフェースを通して外部に公開されるふるまいとの対応関係を明示的に記すための語、と解釈すればよいであろう。 “初期化時の値” は,この初期化により設定された値を指す — すなわち,初期化された値が,スクリプトなど外部から影響されないことを明示する(言い換えれば、次項の “設定子” により設定される値と区別する)ための語と解釈すればよいであろう(読み取り専用の属性に対し用いられることが多い)。
“取得子( On getting, ... / ...’s getter )”
“設定子( On setting, ... / ...’s setter )”
特に IDL 属性に対し、外部(スクリプト側)から “値の取得/設定アクセスが試みられたとき” のふるまいを記すための略語として用いられる。 ( 原文の getter, setter の表記は、 2015 年頃から増えてきている( JavaScript 言語の影響?)。 )
設定子のふるまいを定義する手続きに現れる句 “所与の値” は、字義どおり設定子に与えた値を意味するが、正式には, WebIDL に定義される 所与の値 を指す。
“新たな ( [create] a new )”
” に記された型のオブジェクト — IDL インタフェースを実装するオブジェクト, または,仕様が規定する概念的なオブジェクト — のインスタンスを新たに作成する(構築する)ことを意味する(すなわち,既存のどのオブジェクトとも “同じでない” — したがって, primitive データ型には この語は利用され得ない)。
その他に(暗黙的に)新たなインスタンスが作成される機会としては、複製するとき(例: “の複製(またはクローン)”, 等)/ リテラルで値を与えるとき(例: “«1, 2, 3»” は、新たなリストを作成する)が挙げられる。
オブジェクトを返す一部の API には、新たなインスタンスを返すか既存のそれを返すか明確に指定されていないものもある(多くの場合,その種のふるまいは、 IDL にて [SameObject] / [NewObject] 拡張属性を用いて指定されるか, API を定義する注釈文にて指定されるが)。 この場合のふるまいは、実装に依存することになる(であろう — 意図的に実装に委ねられていると見受けられることが多いが、単なる指定漏れや,モデルの意味論から暗黙的に推定できる場合もあるかもしれない)。
null
一般的には、意味のある値を持たないことを意味する特別な定数を表す(値 null をとる 2 つのものは,同じと見なされる)。 概念上は、抽象 null 値, IDL null 値( IDL nullable 型がとり得る特別な値 null ), JavaScript null 値, 等々の区別があるが、これらは,一般に交換可能に利用される(言い換えれば、比較時に区別されることはない)。
ε
存在しないことを表現する特別な定数( null と同様に、値 ε をとる 2 つのものは,同じと見なされる)。 この記号は和訳に特有であり、アルゴリズムや定義の記述を形式化して,簡潔に述べるために導入している — 仕様にてこの意味を表す値として明示的に null が利用される場合もあるが、そうでない場合も多々あるので。
一部の仕様の和訳では、仕様にて null で表現されている場合でも, IDL とは異なる文脈下にあることを明確化するために ε を利用している。
失敗( failure )
アルゴリズムが返す 失敗 は,期待される結果が得られなかったことを表現する特別な定数であり、特に,構文解析アルゴリズムに利用されることが多い(入力を構文解析できなかったことを指示する)。
true, false
一般的には,真偽値を意味する特別な定数を表す。 概念上は、抽象 真偽値, IDL boolean 型値, JavaScript boolean 型値の区別があるが、 null と同様,これらは交換可能に利用される。
“〜 フラグ( flag )”
“〜 モード( mode )”
“〜フラグ” という名前は、主に,[ アルゴリズム/抽象オブジェクトのふるまい ]の制御目的に利用される, 2 つの状態をとり得る変数やプロパティに用いられる。 3 つ以上の状態をとり得る変数に,この名称が用いられることはなく、その種の制御変数は,通例 “〜モード” と命名される。 フラグの状態は、真偽値(特に, IDL boolean 型値としてそのまま API に公開されるもの)や,意味を伴う名前が付与された定数で表現されることもある一方で,英文では[ is set ( “何かが設定されている” )/ is unset( “何も設定されてない” ) ]で表現されることも多い。 が,和訳においては、常に明示的な値 — 通例的には真偽値( true / false ) — で表現している (そのままだと、[ 日本語/アルゴリズム表記法(次節に述べる) ]で表現するには都合が悪いので)
アルゴリズムの入力として与えられるフラグ “ 〜フラグ ” は、[ “フラグ” を除いた部分を成す名前の定数, 上述の ε ]の 2 値をとり得るように定義されることもある(当のアルゴリズムを呼び出している箇所の引数を[ true / false ]で記した場合、意味が明らかにならないので)。 また、アルゴリズムを呼び出す際に省略され得る — その場合のフラグの値は、明示的に省略時の値が定義されていない限り,暗黙的に “ε” をとる。 (英語的感覚では、“unset” と ε は,同義と考えられる。)
オブジェクトに結び付けられているフラグは、 “オブジェクトは X である” という意味を, “X フラグ は true ” という形に形式化して反映している場合が多い。 その種のフラグは、初期時は false をとるものと(暗黙的に)規定されることが多いが,例外もある。
“段( step )”
“手続き( steps )”
“段” は、手続き/アルゴリズムの記述を構成する 1 個の ブロックを指す。 具体的には、手続きのマークアップ表現における,順序リスト( OL 要素)の中のリスト項目( LI 要素)で表現される 1 個のブロック(入れ子階層の末端のブロックに限らず)。 例えば “前段” は、その “前段” と記されたブロックと同じ階層レベルの,直前のブロックを指す。 ( “手続き” は、 “procedure” の訳語でもあるが、この語が現れることは滅多にない。 )
“下位手続き( substeps )”
ある手続きの記述の中で、(通例的には†)入れ子に記述され,独立な実行単位と見なせる手続きを指す( “次の下位手続きを走らす…”, 等々)。 一般に,下位手続きは、上位の手続きで利用されている変数や引数をそのまま参照するが,実行制御の視野は 当の下位手続きに絞られる — 特に,下位手続きの中での RETURN (次節を見よ)は、上位の手続きではなく,当の下位手続きを終了させる。 ( JavaScript のクロージャ関数(関数内に定義される関数)に似る。) († 入れ子ではなく、別の場所に記される場合もしばしばある。 元々の原文がそう記述されていることもあれば、長大なので分けた方が見通しが良くなるなどの理由から,和訳にてそう記述することもある。 )
この語は、上位の手続きが呼び出した 非同期に実行される演算に対し,その結果を取り扱う手続きを指すときに利用されることも多い。
注記: 表記法(次節)の都合から、和訳では,原文の “substeps” すべてを,そのまま “下位手続き” と訳してはない ( 加えて、原文の “substeps” の用法自体も以前から変化してきている ) 。 実行制御の視野を変えたくない/変える必要のない所では、訳から外している (単に下位ブロックとしてマークアップする, 等)。 逆に、手続きの中の一連の段を下位手続きとして記述し直すこともたまにある — 実行制御の視野を絞った方が簡潔に記述できる場合など。
foo 手続き
IDL メンバ foo に対する “foo 手続き” のような句は、 foo のふるまいを定義している手続きを指す。 foo が IDL 属性の場合、手続きには取得子, 設定子の両方があり得るので、[ “foo 取得子の手続き” / “foo 設定子の手続き” ]のように記される。
この句は、[ 当の IDL メンバが作者スクリプトにより上書きされようが,当の手続きに従ってふるまう ]ことを明示的に指示するためとして,一部の仕様で利用されている。
フック( hook )
拡張能を得るために、当の仕様が,自身が規定する手続きのある段を[ 外部(他の仕様など)から供される処理を( callback 関数のように)実行する場 ]として,提供するもの。 (参考) (その目的の一つは、他の仕様による monkey patch を避けることにある。)
arg(省略時は 既定値
アルゴリズムを導入する記述において,その入力を成す引数 arg がこのように記されている場合、[ アルゴリズムを呼び出すとき arg を省略できる ]こと, および[ 省略された場合、 arg には自動的に 既定値 があてがわれる ]ことを表す。
arg は与えられていない
arg = ε
API メソッドのふるまいを定義する手続きに現れるこの句(条件)は、概略的には,引数 arg を省略してメソッドが呼び出されたことを表すが、正式には[ WebIDL に則って arg を IDL 値に解釈した結果は、特別な値 missing になった ]ことを意味する。

ここでの arg は、当のメソッドに宣言された引数であって,次をすべて満たすことが前提にある:

そのような引数に明示的に JavaScript undefined 値を渡してメソッドを呼び出した場合も、 missing に解釈される。

(可変個引数(宣言に "..." が付与されたもの)に渡された undefined は、必須の引数と同様に解釈される。) (†省略可能な引数のうち, "= 既定値" が宣言されているものは、その引数を省略した場合,既定値として 既定値 を渡したものと見なされる。)

arg = ε” (その否定は ≠ )という表記は、まだ導入してから日が浅いので,和訳に反映していない仕様もある。

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

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

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

表記 意味
Assret条件 いわゆる表明。 条件 で表現される暗黙的な不変則を明示的に示して,アルゴリズムの明確化を図るものであり、アルゴリズムの意味論に要件を追加するものではない。 アルゴリズムの入力が満たしているはずの条件が記されることが多い。
これ° 文脈オブジェクトcontext object )/ IDL this 値 ]の略記。 論の対象のインタフェース(またはインタフェース mixin )のメンバ(メソッド/属性取得子/属性設定子)が呼び出されているオブジェクト自身(その種のメンバを定義しているインタフェース(またはインタフェース mixin )を実装している,ある特定のインスタンス)を指す。 通常、そのメンバのふるまいを規定するアルゴリズムの中で用いられる。 この用語は頻出するので、和訳ではこの略記に代えている。
アルゴリズム名( 引数… ) アルゴリズム名 が指示する手続きを 引数 ( 0 個以上)を渡して適用することの略記。
O 上の foo 手続き( 引数… ) IDL メンバ foo を実装しているオブジェクト O 上で, foo 手続きに所与の 引数 ( 0 個以上)を渡して適用することの略記。 その手続き内の これ° は、 O を指すことになる。
ε 存在しないことを表現する特別な定数( 詳細は上述に )。
, , ¬

論理演算用。 2 つの条件文に挟まれた は論理積( “かつ” ), は論理和( “または” )を表す。 条件文の先頭に置かれた ¬ はその否定( “でない” ) を表す。

条件の順序は有意になることもある: の場合、先に現れる条件が満たされない限り( の場合は、その否定が満たされない限り),後に現れる条件が意味を成さないこともあるので。

A B,
A B
AB が同じであることを表す(原文 “A is B” †)。 の否定を表す。 仕様には明文化されていないことも多いが,同じであることの定義は、比較対象が属する型に依存する — 通例的には、比較対象が[ オブジェクトの場合は 同一のインスタンスであるとき / primitive 値の場合は 値が等しいとき ]同じとされる。 ( 複合的な型の各成分の同等性を述べるときは、一般に,専用の用語(例:同一生成元)や下に述べる注釈記号を利用して述べられるか,あるいは各成分を列挙して ( A1, A2, … ) ( B1, B2, … ) のように記される。 ) († “A is a B” は、通例 “A は B である” と訳される。 )
A :← B 新たな変数 A を導入した上で,その値を与えられた値 BB が変数などの値を持つ何かとして記されていれば、その値)に初期化することを表す(原文では “ Let A be B ” と記される)。
AB

既存の変数 A (または、プロパティや属性などの,値を持つ何か)への 値 B の設定(代入)を表す(原文では “ Set A to B ” と記される)。

論理的には、この表記が現れる前後において,次のように変化することを意味する:

  • AB ]を満たしていたなら何も変化しない。
  • AB ]を満たしていなかったならば、それを満たすようになり, A 以外のどの変数(または値) X も[ XA ]を満たしていたならば それを満たさなくなる。

( :← や ← のような記法を用いる理由の一つは、設定(もしくは定義)の日本語表現には “A を B とする”, “A を B に設定する”, “A が B になる”, “A を B にする”, “A は B とする”, …等々,多種多様な言い回しがあり、文脈, あるいは A, B の役割や定義に依存して,どちらが設定される側になるかの解釈も変わり得るため,誤解の余地も生じ易い/文脈を汲み取る労力を要するので。 もちろん,何らかの表現を一貫して用いることは考えられるが、訳者自身もしばしば,どの表現に統一されているのか忘れることがあるので。 要するに翻訳の手間を省くことも目的の一つにある。 )

IDL 属性 A に対するこの表記(あるいは初期化)は、実際には, A に対応する “内部的な下層データ” を設定することを意味する( IDL 属性自身は、アクセス用の演算子に過ぎない)。 この下層データは、仕様には明示的には定義されないことが多い — その場合、 A 属性を定義しているインターフェースを実装する各オブジェクトは、同じ名前の[ 下層データを保持するための “内部スロット” ]を持つものと暗黙的に定義される。

A += n,
A −= n
変数 A に対する増減操作を表す。 += は加算, −= は減算を表し, n はその量を与える。
+, , ×, ÷ (数式の文脈の下で)加減乗除算を表す。 単独の数値/変数に接頭された +, は正負符号を表す。 (負符号 "" は Unicode MINUS SIGN 。 除算は 原文では通例 "/" で記されるが、他の区切り記号にも多用されるので,和訳ではなるべく "÷" を利用している。)
>, , <, (真偽条件の文脈の下で)数値の比較を表す。
AB 値の範囲を表す — A, B も含まれる。 ただし,A > B の場合の範囲は空集合になる(そうなる事例は滅多にないが)。
{ } 括弧内に挙げられた対象の集合を表す。
e S,
e S
e の集合 S への所属( )を表す。 はその否定を表す。 例えば e { a, b, c, … } は、 e が右辺に列挙されたいずれかの項と同じ( )であることを表す。
A 注釈記号 B 注釈記号 が付いた比較は、その記号の定義に基づいて解釈される(例えば “大小無視” は、文字大小無視に基づく文字列の比較を表すなど)。 記号の意味は、個々の仕様の中で定義される。 の代わりに , なども利用される — その論理は 注釈記号 に定義される同値関係に基づく。
IF 条件ブロック 条件 が満たされるときに限り,ブロックの内容を実行することを表す。
ELSE [ IF 条件] :ブロック 直前に現れている, 同じ階層レベルの[ IF および それに後続する ELSE IF ]に与えられた どの条件も,それが評価された時点で満たされなかったときに限り(すなわち,それらのどの ブロック も実行されなかったときに限り)、加えて, IF 条件 が与えられている場合は その条件も満たされるときに限り、 ブロックの内容を実行することを表す。 したがって, ELSE 単独で現れている場合、当の条件節の終端を表すことになる。
に応じて:
条件1
ブロック1
条件2
ブロック2
いわゆる switch 文。 に記された対象が後続の どの 条件1, 条件2, … を満たすかに応じて、対応する ブロック のみを実行する(あるいは,その記述に従う)ことを表す。 各 条件 は、多くの場合,対象がとる[ 値/値の範囲 ]として記される。 その場合、対象の値が[ 示された値と同じ/ 示された範囲に入る ]という条件として解釈することになる。 各 条件 による場合分けは,通例 排他的になるが、そうでなければ何らかの処理規則(例えば, “最初に該当する段を実行する” など)が付記されることになる。
WHILE 条件ブロック 条件 が満たされる間,ブロック の内容を繰り返し実行することを表す。 条件 は、各 繰り返しの最初に評価される。 条件 に “無条件” と記されている場合は無限に繰り返すことを表す( ブロック の中の BREAKRETURN などにより繰り返しを終える)。
( 対象 ) に対し :ブロック ” に記された[ 対象範囲に属する, あるいは条件を満たす ]ような 対象 それぞれについて,その列挙順序が明示的に指定されていれば その順序に従って、ブロック の内容を実行することを表す( “for each” )。 列挙順序が指定されていない場合、一般に,対象範囲が リスト のような元々順序を備えるもの(または その一部)であれば,その順序に従う。 処理結果が列挙順序に依存しないものについては,順序が指示されないこともあるが、依存する場合は実装依存になる可能性がある。
CONTINUE 繰り返しループ( WHILE … / “ ( … )” )において、現在の反復を中断して,次の反復へ移行することを表す。
BREAK 繰り返しループから抜けて,ループブロックの次の段へ移行することを表す。
BREAK ラベル BREAK が記された段の上位レベルにある, ラベル が付与された段 ]全体を中止することを表す( BREAK 以降を走らすことなく, ラベル が付与された段の次の段へジャンプする)。 ラベル が付与された段を “一度だけ反復するループ” と見なせば, BREAK と同じになる(他のループが入れ子にされていない限り)。
GOTO ラベル ラベル が付与された段へジャンプすることを表す。
THROW 例外名

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

† 2 種類の例外[ DOMException, 単純例外 ]どちらのオブジェクトが投出されるかは, 例外名 から判明するので、日本語訳では,その区別を省略している( 単純例外は 5 種しかなく — 少なくとも各仕様の和訳においては — TypeError, RangeError が大部分を占め, EvalError は一握り(CSP 内の一箇所), ReferenceError, URIError は全く現れていない(これらを定義する WebIDL は別として))。 (単純例外と DOMException の両者用に定義されている例外名は、今の所ない — 将来そのような例外名が導入される可能性も否定はできないが、そのような紛らわしい名前は,避けられるであろう)。

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

RETURN [] をアルゴリズムの呼び出し元に返した上で、特に並列的に実行を継続するよう指示されていない限り,現在の手続き終了することを意味する(下位手続きの中では、上位の手続きではなく,当の下位手続きを終了させる)。 を伴わない RETURN は、返り値が無いことを意味する。 呼び出し元のアルゴリズムにて,この返り値を指すときには、通例, “〜した結果”, “〜の返り値” と記される。

語彙の対訳について

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

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

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

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

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

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

例えば “ティ” で終わる語の語尾の長音は、全般的に,長音の有無で意味が変わったり, 長音が省略された語の方だけ使用されない事例はごく稀と思われるので、省略しています( “プロパティ” など)。 動作の主体(動詞の変化形)を表す語尾の長音( “サーバー”, “ユーザー”, “パーサー”, “オブザーバー”, 等々)についても,大半は省略されています(仕様の中ではこの種のものが大勢を占める)。 ( 技術用語で長音が略される傾向が高いのには、実在する動作者と抽象的な役割とを区別したいのも理由にあると思われる。 例えば、ソフトウェアの文脈における “ユーザ” は、人利用者のみならず,利用者を代表して働く構成部品も含めて指している(あるいは実質的にそう見なせる/見なす必要がある)ことが多い。 “オブザーバー” と記されたときは,その種の役職に就いている人を指し、 “オブザーバ” と記されたときは,プログラミング パターンの一種を指すように感じることはないですか? )

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

一覧