Web 関連仕様 日本語訳

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

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

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

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

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

この日本語訳は非公式な文書です（翻訳更新： <日付> ）

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

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

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

©

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

索引など

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

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

日本語訳ページ一覧

各ページに共通な機能

本文ダブルクリック
ページの左右端をクリック
当該箇所の原文を表示。
ページ左下隅のボタン
目次のサイドメニュー化切替（アクセスキー A ）
索引を表示（用語やインタフェースメンバなど）（アクセスキー S ）
原文の全表示切替（アクセスキー Z ）
語彙の対訳切替（アクセスキー X ）
見出しや定義項目†のクリック
† id が付与された項目 （具体的には、 章や節の見出し, 定義された用語, 定義されたコード（値型, インタフェースメンバ, CSS プロパティなど）の名前, 定義リストの見出し, 参照文献の見出し, 等々）。

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

  • その項目自身を指すリンク

    リンクテキストには、 章／節 の見出しについては その原文，他の場合は その項目の id が示される。

  • “原文” — 原文内の，対応する同じ項目を指すリンク

    このリンクは、 和訳に限り id が付与されている項目に対しては示されない。 また、自動処理の都合などから、 原文と異なる id が付与されている項目もあるが、 その場合でもリンクは元の id を指すようにしている （逆に，和訳ページが元の id でアクセスされた場合も同様）。

  • “MDN” — MDN サイト内の，対応する項目を指すリンク（一部のみ）

    実装状況や用例など、 Web 開発者向け情報。 該当するページが MDN サイトに実際にあっても， 和訳には まだ付与していないものもある（随時更新）。 また，対応する項目が複数ある場合でも、 （現時点では，代表的な） 1 個しか示されない。

  • 同じページ内の，その項目を指しているリンク一覧 （パネル表示中は、左右矢印キーにより，これらのリンクを巡回できる）

“原文”, “MDN” を指すリンクは、 新たなタブ（またはウィンドウ）内に開かれ， それ以降も同じタブが再利用される （再利用させたくない場合、 文脈メニューなどを介して，明示的に指示する必要がある）。

画像や図式のクリック
場合によっては、 代替テキストが示される （［ 代替テキストが無い／同じ内容が周囲のテキストにもある ］ときなど、 示されない場合もある）。

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

各ページに共通な表記規約

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

スタイル

リンクは、次の３種の下線スタイルで呈示されます：

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

見本コードなどのコードブロック（ pre ）において， 可用な幅に収まり切らない行は、 自動改行して呈示されます。 同様に，可用な幅に収まり切らない画像は、 収まるよう縮小して呈示されます。

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

マークアップ

基本的には，原文に即する様にしてありますが、 次に挙げる理由から，利用するマークアップ構造を改めている箇所もあります：

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

約物，記号類

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

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

記号 説明／用法（原則）
隅付き括弧 【, 】 訳者による【注釈／原文の補完】。
全角 丸括弧 （, ） 後述の全角ダッシュとは対照的に、 主として，補助的な説明や例を挿入するために利用される （例えば、この括弧内に記した句のように）。
半角 丸括弧 (, ) 主として，地の文の中で、 アルゴリズムの入力引数, あるいは数式を括るときに利用される。 （全角と見た目の区別が付きにくいが、文脈から容易に判別できるであろう。）
全角 角括弧 ［, ］ 修飾や条件などの対象範囲を明確化するための括り。 例えば、 ［［列挙された多数の語句］や長い語句］を文の中で一体として扱うとき， あるいは 読点の結合順位（後述）だけでは不足する場合など （例えばこの文では、 内側の ［, ］により “列挙された” が “長い語句” にかからないようにした上で， “一体として扱われる” 対象を明確化するために外側の ［, ］で括っている）。 特に必要がない所でも，同じパターンが繰り返されるときは、 パターンを強調するために利用されることがある。 また、長文の構造を読み取り易くする際にも利用される。 （これは、［ 話し言葉のように一息に話すことにより，ひとまとまりを表現するような柔軟性 ］を，多少なりとも書き言葉に付与するためのものでもある。 また、 書き言葉であるからして，発音できない各種記号を使わない手はないであろう — 語句の順序を 論理的な流れを追い易いものに保ちつつ，曖昧さを排除するためにも。 厳密さを追求するなら、 記号に頼らず，あらゆる関係構造をマークアップに落とし込んだ上で， CSS で呈示に反映させるのが理想であろうが。）
全角コロン "：" コロンの前の語句に，後続の文やブロックでその説明や定義を与える（特に，説明が長くなる場合）。
句点 "。" 句点は "。" に統一。
全角読点 "、",
全角カンマ "，",
半角カンマ "," 		結合度の低い順に，左の３種類が読点として利用される。 結合度が全角読点の一種類で済む場合でも、 連続性が強い所では，カンマが利用される。 また，半角カンマ（＋半角スペース）は、 文脈の中で等格な［ 語句／キーワード ］を列挙する際に特に利用される。 （これらは，実質的に “［, ］” の略記と見なせることが多い。）
全角ダッシュ " — " この文のように，長めの語句を挿入する所 — 丸括弧が補助的な説明を挿入するのとは対照的に，規範的な語句を挿入するときなど — では、 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” と記されても同じことになる。） （英文における “or” に対応するとは限らない。 例えば、 “Y and Z use X” は “［ Y ／ Z ］は X を利用する” と等価になる — 論理的には、 Y, Z について個別的に述べるのと同じことなので。 仮に，この “use” が三人称単数を表す “uses” であったなら、 Y, Z が成す一組としての扱いが意図されることになり， “［ Y, Z ］が成す組は …” などと訳されることになろうが。 また， “Y or Z uses X” は、 “［ Y, Z ］のどちらかが X を利用する”, などと訳されることになろう。）
  • 対応関係の明示： 例えば， “a／b／c は A／B／C である” は、 “a は A であり, b は B であり, c は C である” の省略記法（ “a は B である” 等は除外される）。 この対応関係の範囲は、 特に断らない限り，同じ文の中（すなわち，句点まで）に限られる。 （同順に対応する事例の方が，ずっと多いので、 同順を既定にしている。 同順に限られない場合、 “順不同” が付記される。）
  • 半角カンマの代わりに利用される，等格な語句の区切り （視認性の向上，あるいは 語句に読点が含まれているときなど）。

複数表現を孕む場合、 角括弧による表記法の相違に注意されたし。 例えば、 “ N 個の［英字／数字］からなる” と記された所では，英字と数字が混在し得ることを表す一方で、 “［ N 個の英字／ N 個の数字 ］からなる” と記された所では，英字か数字どちらかのみからなることを表す。

半角スペース “小さな” 区切り：
  • ［英単語, キーワード, 埋め込みコード類］等と 地の文との区切り
  • 読点の結合度の順位数が足りない場合の補助
  • 読点の挿入が不適切な所での、 文節の区切り （例： “〜の間 存続する” のように漢字が連続する地点, あるいは “〜により近づく” のような多義的な解釈 （ “〜により，近づく” ／ “〜に，より近づく”） が生じる所での一義化）
  • より連続性が重視される所での，読点の代わり
  • 同じパターンが繰り返される場合の，読点の省略形
  • ［ 連続する熟語／連続する外来語 ］が長くなるときの区切り （例： “リクエスト ヘッダフィールド” など — このような場合、 意味構造をなるべく保つため， “ヘッダ” と “フィールド” の合間にはスペースは挟まれない）
二重引用符：
（曲線型） “…”
（半角） "…" 		“曲線型” の方は、 通常の引用符 （説明用の［ 比喩的／概念的 ］な記述など）。 “半角” の方は、 仕様が規定するリテラルや記号類, 例示コード類の括りなど， 意味よりも文字列そのものの［ 同一性／忠実さ ］が重視される所で利用される。

これらの記号を多用する理由は、 （前提として多義的に解釈されては困る）仕様の記述には，次に挙げるような資質があるため、 文脈から意味構造を一義的に決定するのが難しくなる傾向があることによる （例えば 「黒い目のきれいな女の子」 ）：

  • 専門性が高いので、 初学者にとっては，初見の用語が数多くある
  • あらゆる事例に対処するため、 条件など様々な修飾が多用される （したがって，文の構造も複雑になる）
  • 前項と同じ理由で, あるいは 将来の拡張能を担保するため、 抽象的な用語が多用される （例：いくつかの具象的な何かの総称として）
  • 様々な処理を適用する結果，［ 動作が表す意味と実際に現れる結果が合致しない例外的な場合もある ］ことが “普通” なので、 断定的な表現より，間接的な表現が多用される（ “〜になり得る”, 等々）
  • Web に関係する仕様の大きな特質として，［ 旧い仕様に基づいて作成された既存の内容 ］との互換性を保つ必要があるため、 何層にも重ねられた複階的な要件が数多くある。
  • 言語を規定するメタ言語的な側面もあるので、 遠回しな（入れ子にされた）表現が多用される （ “〜になるように〜することを確保しなければならない”, 等々）
  • 説明などの補助的な内容は最小限に抑えられていたり， 互いに関連する内容が様々な［ 箇所／仕様 ］に分散しているため、 “ストーリー” に乏しい （それら各内容からなる無数の組み合わせのそれぞれが “ストーリー” を構成するので、 “代表的な一つ” に絞れないことも多い）

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)／ 省略時は〜 (*5) (c)

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

共通な慣用表現

多くの仕様では，以下に挙げる慣用句を利用しています（括弧内は原文の表現）：

“各 O には P が結び付けられる （ O has an associated P ）”
“〜を有する” ／ 〜の” ／ “〜に属する”

この句には、 一般に，次が含意される：

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

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

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

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

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

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

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

  • 結び付けによる関係が専属的であれば、 V から それを結び付けている O が一意に定まり、 V に変更が加えられても， C に属する他の個体には影響しないことになる。
  • 専属的でない場合（ C に属する複数の個体が，同じ V を共有し得る）、 そのことを明らかにする目的で，和訳では “O は V に属する” という句で表現することもある。 この場合、 O に対応する V を指すときは， “O が属する P ” という句で表現される。 また， V を結び付けている［ C に属する個体の集合 ］を指すときは、 “V に属する O （たち）” という句も利用される。 （ “属する” という語が意味論的に相応しくなければ、 他の語を利用することもある。）
P が primitive 値の集合である場合、 “異なる各値ごとに 1 個しか存在し得ない” と解釈する （そう解釈すれば、統一的に扱えるので都合が良い）。 この解釈の下では、 どの primitive 値も それを P 値にとる C に属するすべての個体から共有されることになり、 通例， “専属的” にはなり得ない。
“結び付け” と同じ, または よく似た意味で “紐付け‎” という語も一般によく見受けられる — が、その “紐付け” は、 “link” ／ “relation” ／ “connect” ／ “bind” など，違う意味かもしれない。
“当の〜”
［ この語が利用された文脈により，一意に識別されるべき何か ］を指すときに利用される （多くの場合、 "the" の対訳を成す）。
primitive データ型
技術的な分類は，個々の人工言語ごとに様々な定義があろうが、 一般概念としては，［ 値それ自体が 個を識別するものとしても働くデータ型 ］と捉えて差し支えないと見受けられる — すなわち，そのような 2 つの値 a, b があって “等しい” ならば、 a, b は “同じ（同じ個体）” と見なされる （オブジェクト的には、変異不能なオブジェクトである）。 具体的には、 文字列, 真偽値, 数量的な値, 抽象的な定数など。 リスト（配列）やマップなどの複合的な型（コンテナ型）は、 基本的な型ではあるが）この捉え方においては， primitive データ型とは見なされない — これらは一般に，オブジェクトとして扱われ、 異なる個体は，各成分が互いに等しくても “同じ” とされない。 （文字列は、 文字たちが成す配列であるとして，複合型に分類される言語もあるが、 Web プラットフォームにおいては，一般に primitive データ型とされる。 配列として扱われる（変異可能な）文字列は、 通例的に “バッファ” , 等々と称され，文字列と区別されることが多い。）
“新たな 〜 （ [create] a new 〜 ）”
“〜” に記された型のオブジェクト — IDL インタフェースを実装するオブジェクト, または，仕様が規定する概念的なオブジェクト — のインスタンスを新たに作成する（構築する）ことを意味する（すなわち，既存のどのオブジェクトとも “同じでない” — したがって、 primitive データ型には，この語は利用し得ない）。
その他に（暗黙的に）新たなインスタンスが作成される機会としては、 複製するとき （例： “〜の複製（またはクローン）” 等）／ リテラル値として与えるとき （例： “«1, 2, 3»” は、 新たなリストを作成する） が挙げられる。
オブジェクトを返す一部の API には、 新たなインスタンスを返すか既存のそれを返すか明確に指定されていないものもある （多くの場合，その種のふるまいは、 IDL にて［ [SameObject] ／ [NewObject] ］拡張属性を利用して指定されるか， API を定義する注釈文にて指定されるが）。 この場合のふるまいは、 実装に依存することになる （であろう — 意図的に実装に委ねられていると見受けられることが多いが、 単なる指定漏れや，モデルの意味論から暗黙的に推定できる場合もあるかもしれない）。
“〜群”
この接尾辞は、 一群の何かからなるが，データ構造としては 1 個のオブジェクトとして数えられるもの — リストやマップなど — を簡便に記す（特定のデータ構造を指定せずに記す）ために利用される。
通例的には、英文において複数形で記される語のうち， そのようなコンテナ型の値を表すものの対訳に利用される （例： options は “オプション群” と対訳される）。 （他の複数形は、必要な所では — “すべての〜”, “各〜” など，文脈から複数個あり得ることが明らかな場合を除き — “〜たち” などと訳される）。
〜個目
〜番
index （順序付けられた連列内の，ある特定の位置を指すもの）は、 一般に，［ 1 から数える場合は “〜個目”（あるいは “〜本目”, 等々）／ 0 から数える場合は “〜番” ］と表記される （例：所与の文字列 S を成す［ 0 番の文字, 1 個目の文字 ］は、 どちらも， S を成す最初の文字を指す）。
null
一般に，意味を有さない値であること — あるいは単純に “無い” こと — を意味する特別な定数を表す （値 null をとる 2 つのものは，同じと見なされる）。 概念上は，［ 抽象 null 値, IDL null 値（ IDL null 可能 型がとり得る特別な値 null ）, JavaScript null 値, 等々 ］の区別があるが、 これらは，一般に交換可能に利用される （言い換えれば、 比較時に区別されることはない）。
ε
存在しないことを表現する特別な定数 （ null と同様に、値 ε をとる 2 つのものは，同じと見なされる）。 この記号は和訳に特有であり、 アルゴリズムや定義の記述を形式化して，簡潔に述べるために導入している — 仕様にてこの意味を表す値として明示的に null が利用される場合もあるが、 そうでない場合も多々あるので。
一部の仕様の和訳では、 仕様にて null で表現されている場合でも， IDL とは異なる文脈下にあることを明確化するために ε を利用している。
失敗（ failure ）
アルゴリズムが返す 失敗 は、 期待される結果が得られなかったことを表現する特別な定数であり、 特に，構文解析アルゴリズムに利用されることが多い （入力を構文解析できなかったことを指示する）。
true, false
真偽値を表す特別な定数 — true は真（条件が満たされる）, false は偽（条件が満たされない） を表現する。 概念上は，［ 抽象 真偽値, IDL boolean 型値, JavaScript boolean 型値 ］の区別があるが、 これらは，交換可能に利用される （ null のときと同じく）。
“〜フラグ（ flag ）” ／ “〜か”
“〜モード（ mode ）”
“〜フラグ” または “〜か” という名前は、 主に，［ アルゴリズム／抽象オブジェクトのふるまい ］の制御目的に利用される［ 2 つの状態をとり得るもの（変数やプロパティ） ］に利用される。 3 つ以上の状態をとり得るものには、 この名称が利用されることはない — その種の制御変数は、 “〜モード” と命名されることが多い。 フラグの状態は、 真偽値（特に， IDL boolean 型値としてそのまま API に公開されるもの）や 意味を伴う名前が付与された定数で表現されることもある一方で， 英文では［ is set （ “何かが設定されている” ）／ is unset（ “何も設定されてない” ） ］で表現されることも多い。 が，和訳においては、 常に明示的な値 — 通例的には真偽値（ true ／ false ） — で表現している （そのままだと、［ 日本語／アルゴリズム表記法（次節に述べる） ］で表現するには都合が悪いので） 。
和訳では、 ほとんどの “〜フラグ” を “〜か” に改称している — これらは、その “処理を制御する資質” から，その意味は動詞に基づくものが多く、 “〜フラグ” のように名詞化を強制すると，日本語として［ 意味が曖昧になる／意味を明瞭化しようとすると まわりくどくなる ］ことが多いからである（例： “canceled flag” は、 “取り消されたか” のように訳される — “フラグ” を接尾するなら、 “取り消しフラグ”, “取り消されたフラグ”, あるいは もっと冗長に “取り消されたか否かを指示するフラグ” のように訳すことにもなる）。 加えて，これらの真偽値をとるものは、 新たに定義される用語では “フラグ” を付与しない名前で表現される （あるいは、既存の “〜フラグ” から “フラグ” が除去される） ことが多くなっている。 これらの名前は — 特に、説明文など，地の文の中では — 語尾の “か” を省いて参照されることもある （例： “…は取り消されたならば…” ） — それは、当のフラグが true に設定されたことを含意する （否定形で参照された場合（例： “…は取り消されなかったならば…” ）は false に設定されたことを含意する） （原文でも、 “flag” を省いた動詞だけで表現されることはよくある） 。
アルゴリズムの入力として与えられるフラグ “〜フラグ” や “〜か” は、［ 語尾の［ “フラグ” ／ “か” ］を除いた部分を成す名前の定数, 上述の ε ］の 2 値をとり得るように定義されることもある （当のアルゴリズムを呼び出している箇所の引数を［ true ／ false ］で記した場合、意味が明らかにならないので）。 また、アルゴリズムを呼び出す際に省略され得る — その場合のフラグの値は、 原文では，暗黙的に “ε をとる” ものと（暗黙的に）見なされていることもあるが、 和訳では常に，当のアルゴリズム定義の中で明示的に省略時の値を指定するようにしている。 （英語的感覚では、 “unset” と ε は，同義と考えられる。）
オブジェクトに結び付けられている “X フラグ” （または “X か” ）は、 “オブジェクトは X である” という意味を “X フラグ は true ” という形に形式化して反映している場合が多い。 その種のフラグは，初期時は false をとるよう定義されることが多いが、 例外もある。
∧, ∨, ¬
2 つの条件に挟まれた［ ∧ は論理積（ “かつ” ）／ ∨ は論理和（ “または” ） ］を表す。 条件の先頭に置かれた ¬ はその否定（ “でない” ） を表す。
∧, ∨ を同時に利用する所では（条件が 3 つ以上ある場合）、 常に，どちらが優先されるかが指示される — 括弧やマークアップによる入れ子により。
条件は、 それを適用する対象が無い場合には，真に評価される — 条件自体が何かの有無を問うものである場合は別として。 例えば， “集合 S を成す どのアイテムも 〜 を満たす” の様な条件は、 “〜” が何であれ， S が空ならば真に評価される （これは、 有無を問う条件 “〜 を満たさないアイテムは無い” と同義でもある）。 対して， “集合 S を成す あるアイテムは 〜 を満たす” の様な条件は、 有無を問うものなので （ “〜を満たすアイテムが在る” と同義）， S が空ならば偽に評価される。
条件の順序は、 意味論的には，有意になることもある： ∧ の場合、 先に現れる条件が満たされない限り （ ∨ の場合、その否定が満たされない限り）， 後に現れる条件が意味を成さない — すなわち，条件を適用する対象が無い — こともあるので （例：［ O は foo プロパティを有する ］∧［ O の foo プロパティの値は 〜 に等しい ］の様な条件）。 逆順に記されたとしても、 論理的には，前述したとおり同義になるが。
∧↓ …
∨↓ …
後続する条件リストに挙げられた条件たちを所与の論理演算で結合した結果の条件を表す。
これは、 ¬ と組み合わせて利用されることもある。 例えば， "¬ ∧↓" （ ∧↓ の否定）は、 条件リストを成す いずれかの条件が満たされない条件を表す。
A ＝ B
A ≠ B
＝ は A と B が同じであることを表す（原文 “A is B” †）。 ≠ は ＝ の否定を表す。
仕様には明文化されていないことも多いが，同じであることの定義は、 比較対象が属する型に依存する — 通例的には、比較対象が［ オブジェクトの場合は 同一のインスタンスであるとき ／ primitive 値の場合は 値が等しいとき ］同じとされる。 （複合的な型の各成分の同等性を述べるときは、 一般に，専用の用語（例：同一生成元）や下に述べる注釈記号を利用して述べられるか，あるいは各成分を列挙して ( A1, A2, … ) ＝ ( B1, B2, … ) のように記される。） （† “A is a B” は、 通例 “A は B である” と訳される。）
>, ≥, <, ≤
（真偽条件の文脈の下で）数値の比較を表す。
{ A 〜 B }
A 以上 B 以下の範囲を表す。 したがって， A > B の場合、 範囲は空集合になる （そうなり得る事例は滅多にないが）。
{ … }
括弧内に挙げられた対象たちが成す集合を表す。
e ∈ S
e ∉ S
e の集合 S への所属（ ∈ ）を表す。 ∉ はその否定を表す。
例えば e ∈ { a, b, c, … } は、 e が右辺に列挙されたいずれかの項と同じ（ ＝ ）であることを表す。
A ＝注釈記号 B
注釈記号 が付いた比較は、 その記号の定義に基づいて解釈される （例えば “＝大小無視” は、 文字大小無視に基づく文字列の比較を表すなど）。
記号の意味は、 個々の仕様の中で定義される。 ＝ の代わりに ≠, ∈ なども利用される — その論理は 注釈記号 に定義される同値関係に基づく。
+, −, ×, ÷
（数式の文脈の下で）加減乗除算を表す。 単独の［ 数値／変数／数式 ］に接頭された +, − は正負符号を表す。
（負符号 "−" は Unicode MINUS SIGN 。 除算は 原文では通例 "/" で記されるが、 他の区切り記号にも多用されるので，和訳ではなるべく "÷" を利用している。）
段（ step ）
手続き（ steps ）
“段” は、 手続き（アルゴリズムの本体）を構成する 1 個の ブロックを指す。 具体的には、 手続きのマークアップ表現における，有順序リスト（ ol 要素）の中のリストアイテム（ li 要素）で表現される 1 個のブロック（入れ子階層の末端ブロックに限らず）。 例えば “前段” は、 その “前段” と記されたブロックと同じ階層レベルにおいて その直前にあるブロックを指す。 （ “手続き” は “procedure” の定訳でもあるが、 この語が現れる仕様は，ごく限られる — 実質的に同義なので、 和訳では同じ対訳を利用している。）

手続きは、 他の手続きの中に入れ子にされることもある。 ある手続き（ “上位手続き” ）の中に入れ子にされた一連の段が成すブロックは、 その冒頭に “手続き” を含んでいる句（例： “次の手続きを遂行する…” ）を伴うとき， 入れ子にされた手続き（ “下位手続き” ）であることを指示する。 加えて、並列的に遂行するよう指示されたブロックも，暗黙的に入れ子にされた手続きと見なされる。 入れ子にされた手続きは、 上位手続きの引数や その中で宣言された変数をそのまま参照するが、 その中に現れる RETURN （次節を見よ）は， 当の手続きのみを終了させる （値を返すものは、上位手続きに結果を返す） （ JavaScript のクロージャ関数（関数内に定義される関数）と同様にふるまう）。

下位手続き
入れ子にされた手続きは、 ときには，上位手続きの外側（概して，その直後）に記されることもある （元々の原文にて，そう記述されていることもあれば、 長大なので分けた方が見通しが良くなるなどの理由から，和訳にてそう記述することもある）。 そのような場合、 “下位手続き” という句で， そのことが指示される （それらが、［ 通常の独立な手続きではないこと, 上位手続きの引数や変数を参照していること ］を指示するため）。
引数（省略時は 既定値 ）
アルゴリズムを導入する記述において，その入力を成す 引数 がこのように記されている場合、［ アルゴリズムを呼び出すとき 引数 を省略できる ］こと, および［ 省略された場合、 引数 には自動的に 既定値 があてがわれる ］ことを表す。
“初期化される（ is initialized to ）”
“初期化時の値（ value it was initialized to ）”
“初期化される” という句は，多くの場合、 特に IDL 属性に対する，内部（仕様が定める処理モデル）からの値の設定を記す際に利用されている （必ずしも， “一度限り” を意味するわけではないことに注意）。 仕様が定める概念的なモデルと, IDL インタフェースを通して外部に公開されるふるまいとの対応関係を明示的に記すための語、 と解釈すればよいであろう。 “初期化時の値” は，この初期化により設定された値を指す — すなわち，初期化された値が，スクリプトなど外部から影響されないことを明示する （言い換えれば、次項の “設定子” により設定される値と区別する） ための語と解釈すればよいであろう （読み取り専用の属性に対し利用されることが多い）。
取得子（ getter ）
設定子（ setter ）
これらの語は、 JS のオブジェクトプロパティと同様に， IDL 属性の値を［ 取得する／設定する ］ためのアクセス子を表す — 次項の［ 取得子手続き／設定子手続き ］を見よ。
構築子手続き（ constructor steps ）
メソッド手続き（ method steps ）
取得子手続き（ getter steps ）
設定子手続き（ setter steps ）
IDL メンバ（構築子／メソッド／属性取得子／属性設定子）のふるまいを定義するときは、 これらの句を利用して導入される。
例： “foo() メソッド手続きは…” （以下, 手続きの内容が後続する）
これらの（ Web IDL 仕様により推奨される）句は、 導入されて日が浅いので（ 2020年 5月頃），まだ利用されていない仕様もあるが、 ほとんどの日本語訳では原文に先行して採用している。 これらの手続きは、以前は［ “…'s construcor, when invoked, …”, “… method, when invoked, …”, “On getting, …”, “On setting, …” ］のような句で導入されていた。
設定子手続きに現れる句 “所与の値” は、 字義どおり設定子に与えた値を意味するが， 正式には Web IDL に定義される所与の値を指す。
構築子手続きにおいては、 新たなインスタンスを［ 作成する／返す ］段は省略される — それが受け持つのは、 当のインスタンス（後述の これ° で指示される）を適切に初期化することに限られるので （構築子は、構築子手続きが例外を投出しない限り，当のインスタンスを返すことになる）。
これらの句で導入された ふるまいの要件レベルは、 他が指定されない限り， “〜するものとする（ UA に課される MUST ）” になる。
foo 手続き
API 用に定義される手続きは、 スクリプトからの利用が意図されるが，仕様内の一部のアルゴリズムからも直に呼び出されることがある。 IDL メンバ foo に対する “foo 手続き” のような句は、 foo のふるまいを定義している手続きを指す。 foo が IDL 属性の場合、 手続きには取得子, 設定子の両方があり得るので，［ “foo 取得子手続き” ／ “foo 設定子手続き” ］のように記される。
この句は、［ 当の IDL メンバが作者スクリプトにより上書きされようが，当の手続きに従ってふるまう ］ことを明示的に指示するためとして，一部の仕様で利用されている。 （ほとんどの仕様では、 取得子手続きを呼び出す所では， 単に “foo 属性の値” と記される。）
引数 ＝ ε
API メソッドのふるまいを定義する手続きに現れるこの句（条件）は、 概略的には，引数 を省略してメソッドが呼び出されたことを表すが、 正式には［ Web IDL に則って 引数 を IDL 値に解釈した結果は、 特別な値 missing になった ］ことを意味する。

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

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

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

フック（ hook ）
拡張能を得るために、 当の仕様が，自身が規定する手続きのある段を［ 外部（他の仕様など）から供される処理を（ callback 関数のように）実行する場 ］として，提供するもの （参考）。 （その目的の一つは、 他の仕様による monkey パッチを避けることにある。）

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

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

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

次に挙げる記号についての説明は、前節を参照されたし： ∧, ∨, ¬ ＝ ≠, ε, +, −, ×, ÷ >, ≥, <, ≤, 〜

Assert：条件
いわゆる表明。 条件 で表現される暗黙的な不変則を明示的に示して， アルゴリズムの明確化を図るものであり、 アルゴリズムの意味論に要件を追加するものではない。 アルゴリズムの入力が満たしているはずの条件が記されることが多い。
これ°
IDL this 値 の略記。 論の対象のインタフェース（インタフェース mixin も含む）のメンバ （メソッド／属性取得子／属性設定子）が呼び出されたオブジェクト自身 — その種のメンバを定義しているインタフェースを実装している，ある特定のインスタンス — を指す （ JavaScript の “this 値” に似るが、 定義は異なり，ずっと限定的である）。 ほとんどの場合、当のメンバのふるまいを定義するアルゴリズムの中で利用される。
構築子手続きの中でも利用され、 当のインタフェースを実装する新たなインスタンスを指す。
この用語は頻出し，原文では単に “this” と記されるが、 日本語的にすわりが悪いので （および JavaScript の this と混同されないよう）， 和訳では これ° と表記される。
アルゴリズム名( 引数… )
アルゴリズム名 が指示する手続きを 引数 （ 0 個以上）を渡して適用することの略記。
アルゴリズム名( ↓ ) ：引数ブロック
前項と同じ意味だが、 引数たちは 引数ブロック 内に（概して， 1 行に 1 個ずつ）列挙される。 この表記は、［ 引数の個数が多い／ いくつかの引数は 長い注釈を伴うか名前が長い ］ときに，複数行に分けて可読性を改善するために利用される。
O 上の foo 手続き( 引数… )
IDL メンバ foo を実装しているオブジェクト O 上で， foo 用に定義された手続きを — 所与の 引数 （ 0 個以上）を渡して — 適用することの略記。 その手続き内の これ° は、 O を指すことになる。
A :← B
新たな変数 A を宣言した上で，その値を所与の値 B （ B が値があてがわれた何か（変数など）として記されたならば、その値） に初期化することを表す （原文では “ Let A be B ” と記される）。
A ← B
既存の変数 A — あるいは、プロパティや属性など，値があてがわれる何か — へ所与の値 B を設定することを表す （原文では “ Set A to B ” と記される）。

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

  • ［ A ＝ B ］を満たしていたなら何も変化しない。
  • ［ A ＝ B ］を満たしていなかったならば， それを満たすようになり、 A 以外のどの変数（または値） X も［ X ＝ A ］を満たしていたならば，それを満たさなくなる。
（ :← や ← のような記法を用いる理由の一つは、 設定（もしくは定義）の日本語表現には “A を B とする”, “A を B に設定する”, “A が B になる”, “A を B にする”, “A は B とする”, …等々，多種多様な言い回しがあり、 文脈, あるいは A, B の役割や定義に依存して， どちらが設定される側になるかの解釈も変わり得るため，［ 誤解の余地も生じ易い／文脈を汲み取る労力 ］を要するので。 もちろん，何らかの表現を一貫して用いることは考えられるが、 訳者自身もしばしば，どの表現に統一されているのか忘れることがあるので。 要するに翻訳の手間を省くことも目的の一つにある。）
IDL 属性 A に対するこの表記（あるいは初期化）は、 実際には， A に対応する “内部的な下層データ” を設定することを意味する （ IDL 属性自体は、アクセス用の演算子に過ぎない）。 この下層データは、 仕様には明示的には定義されないことが多い — その場合、 A 属性を定義しているインターフェースを実装する各オブジェクトは、同じ名前の［ 下層データを保持するための “内部スロット” ］を有するものと暗黙的に定義される。
A += n
A −= n
変数 A に対する増減操作を表す。 += は加算, −= は減算を表し， n はその量を与える。
IS 条件
条件 を評価した結果を表現する真偽値を返す。 すなわち、 条件 が［ 満たされるならば true ／ 満たされないならば false ］になる。
IF 条件 ：ブロック
条件 が満たされるときに限り， ブロック の内容を実行することを表す。

これは、 ∧↓ や ∨↓ （および条件リスト）と組み合わせて利用されることもある。 その場合、 ブロック は， 条件リストを成すブロックの後に配置される — 次の様に （文字 “…” は，継続を表現する）：

IF［ ∧↓ ］… 条件リスト …ならば ：ブロック

ELSE [ IF 条件] ：ブロック
直前に現れている, 同じ階層レベルの［ IF および それに後続する ELSE IF ］に与えられた どの条件も，それが評価された時点で満たされなかったときに限り （すなわち，それらに対応するどのブロックも実行されなかったときに限り）、 加えて， IF 条件 も与えられた場合は その 条件 も満たされるときに限り、 ブロック の内容を実行することを表す。 したがって， ELSE 単独で現れている場合、 当の条件節の終端を表すことになる。
〜 に応じて ：分岐リスト

ここでの 分岐リスト は、 次のような形をとるリストでマークアップされる：

条件1
ブロック1
条件2
ブロック2
…
…
いわゆる switch 文。 〜 に記された対象が 分岐リスト を成す どの条件を満たすかに応じて、 対応するブロックのみを実行する（あるいは，その記述に従う）ことを表す。
各 条件 は、 多くの場合，対象がとる［ 値／値の範囲 ］として記される。 その場合、 対象の値が［ 示された値と同じ／示された範囲に入る ］という条件として解釈することになる。
各 条件 による場合分けは，通例的には排他的になるが、 そうでなければ，他が指定されない限り［ 最初に満たされた条件に対応する段 ］に限り実行される。
WHILE 条件 ：ブロック
条件 が満たされる間，ブロック の内容を繰り返し実行することを表す。 条件 は、 各 反復の最初に評価される。
条件 に “無条件” と記された場合、 無限に繰り返すことを表す （ ブロック の中の［ BREAK ／ GOTO ／ RETURN ／ THROW ］などによりループを終える）。
対象範囲 を成す 各 ( 対象 ) に対し ：ブロック
対象範囲 に記された対象範囲に属する — あるいは、 対象範囲 が何らかの条件として表現された場合は，それを満たす — 各 対象 に対し — それらの列挙順序が明示的に指定された場合は，その順序に従って — ブロック の内容を実行することを表す（ “for each” ）。
列挙順序が指定されていない場合、 一般に， 対象範囲 がリストなど元々順序を備える（または，その一部を成す）ものならば，その順序に従う。 処理結果が列挙順序に依存しないものについては，順序が指示されないこともある （依存する場合、 概して，仕様における指定漏れである）。
CONTINUE
繰り返しループ（ WHILE … ／ “各 ( … )” ）において、 現在の反復を中断して，次回の反復へ移行することを表す。
BREAK
繰り返しループから抜けて，ループブロックの次の段へ移行することを表す。
BREAK ラベル
［ BREAK が記された段の上位レベルにある， ラベル が付与されたブロック ］全体を中止することを表す （ BREAK 以降を走らすことなく， ラベル が付与された段の次の段へジャンプする）。 ラベル が付与された段を “一回だけ反復するsループブロック” と見なすならば， BREAK と同じになる （他のループが入れ子にされていない限り）。
GOTO ラベル
ラベル が付与された段へジャンプすることを表す。
THROW 例外名

例外名 で指示される新たな例外オブジェクト†を投出した上で、 特に並列的に実行を継続するよう指示されていない限り， 現在の手続きも終了することを意味する。 例外は、 例外を投出したアルゴリズムを呼び出したアルゴリズムにも伝播する。 すなわち、 呼び出した側も — 当の例外に対する処理 （ “catch する” などの句で指示される） が指定されていない限り — （呼び出した箇所で） 当の例外を投出し直した上で，自身の手続きを終了することになる。

† 3 種類の例外 — 単純例外, DOMException, カスタムな例外（ DOMException を継承するインタフェース） — のうち どれが投出されるかは， 例外名 から判明するので、 日本語訳では，それらの区別を省略している：

  • 単純例外は 5 種しかなく — 少なくとも各仕様の和訳においては — TypeError, RangeError が大部分を占め， EvalError は一握り （CSP 内の一箇所）， ReferenceError, URIError は，まったく現れていない — これらを定義する Web IDL は別として。 （単純例外と DOMException の両者用に定義されている例外名は、 今の所ない — 将来そのような例外名が導入される可能性も否定できないが、 そのような紛らわしい名前は，避けられるであろう）。
  • Web IDL の要件により、 カスタムな例外と DOMException が同じ名前を共有することは決してない。
ECMAScript 言語束縛における例外の投出法を成す具体的な処理は、 Web IDL 仕様にて定義される。
RETURN [値]
値 をアルゴリズムの呼び出し元に返した上で、 特に並列的に実行を継続するよう指示されていない限り，現在の手続きも終了することを意味する （入れ子にされた手続きの中では、 当の手続きのみを終了させる — 上位の手続きではなく）。 呼び出し元のアルゴリズムにて，この返り値を指すときには、 通例， “〜した結果”, “〜の返り値” と記される。

値 を伴わない RETURN は：

  • 当のアルゴリズムがメソッド手続きである場合は、 “RETURN undefined” の略記を表す。 これは、当のメソッドが返り値型 undefined として宣言されていることが前提にある — そのため，そう解釈することが要請される。

  • 他の場合、返り値が無いことを意味する。

    値を返さないアルゴリズムに対し，結果が参照された場合、 ε と見なされる （すなわち，そのようなアルゴリズムにおいては，実質的に “RETURN ε” の略記になる）。 この規約は、値を返すアルゴリズム, 返さないアルゴリズムを統一的に取り扱う必要がある事例のためにある （そのような事例は、稀にしかないが）。

語彙の対訳について

日本語と英語には（特に文の構造に）大きな開きがあるので、 語彙以前に，原文を論理的に等価な言い回しに変形することも よくあります — 例えば，対偶をとるなど。 （挙げていくと際限ないが，実際には、 英語のすべての定冠詞（の有無, あるいは all, every, each 等々）, あるいは語形変化など、 およそすべて， “等価な” 言い回しに変形することになる。 双方の言語には，利用する語彙そのものに異なる視点が組み込まれているので、 より適する言い回しも，必然的に異なることになる。 語の省略法も異なるので、 原文に無い語を補完したり，逆に原文の語を省略することも ときには必要になる。 特に、 英文における［ 単語を分離するスペース ］の対訳として，日本語の助詞（特に “の” ）が利用されることは多い — ときには、 スペースを挟む 2 つの語の関係性を明示的に補完しないと，日本語として［ 意味が通らなくなる／誤解を招く表現になる ］ことすらある。）

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

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

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

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

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

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

一覧