1.0から1.1に向けての修正案件

• Some historical implementations は既存の実装には〜と訳す。
• ツールでの処理(検索・抽出など)を考え、英数は一バイトで統一する。
• A and /or B は、こなれた訳にする。たとえば、<BLOCKQUATE>部分の訳は

  典型的な表示方法としては、左右をインデントする、イタリックで表記する、あるいはインデントとイタリック表記の両方を適用するといったものがあげられる。

  などとしたい。
• 語調を統一する。ですます調かである調か、どちらにすべきか……。 とりあえず「規格書だからである調にしたほうがいい」との意見がでております。
• 訳注を入れるべきか？　やるなら別に解説を書いたほうがいいかも。
• IMGの解説部分の注意書き。

  注:アンカーによってリンクされた画像であれば表示できるHTMLユーザーエージェントであっても、<IMG>による画像は表示できないものもある。

• ALTの解説部分

  この文字列は、処理系の制約やユーザー側の選択しだいで、参照されている画像リソースのかわりに表示される。

• 1.2.1.文書(Documents)の一部を書き換え。

  注 : 昔から作成されていたユーザーエージェントには、いくつかのHTML構文のサポートについて規格に合致しないものがあります。合致しない恐れのある部分については、この仕様書を通して、このような注意書きの中で確認していきます。

  また、準拠しているとなっていた部分を変更。conforms だから規格と一致しないと駄目と思いますんで、合致しているに変えました。準拠だと違っているのもかまわないという意味になりそうで。
• features は機構と訳してしまっていいんですかね？　sgmlsのエラーメッセージでは、そう訳されているようですが。
• 1.2.2.Feature Test Entitiesを結構大胆に訳し変えました。

  HTML.Recommended

  HTML2.0には慣用的に使われてきた仕様との互換性のために必要な機構(features)が残してありますが、それらの機構により文書構造の完全性が損なわれる恐れがあります。この feature test entitiesは構造を損ないかねない機構を除いた、より規範的なDTDを選択します。デフォルトでは`IGNORE'にセットされます。

  HTML.Deprecated

  古い仕様との互換性のために必要となる機構(features)です。しかしこれは既に古びてしまい、実装に矛盾が存在し、使用すべきでは無いものです。このfeature test entitiesは、これらの機構(features)を許可したDTDにします。デフォルトでは`INCLUDE'にセットされます。変換ソフトや編集ソフトで作成された文書には使用すべきでない(deprecatedな)語句を含むべきではありません。

• 1.2.3.ユーザーエージェント(User Agents)
  この部分の訳にはたいへん自信がありません。もとの訳とは別物ですが……意味としてはこっちのほうかなぁと。

  注 : 安定性と拡張性を両立させるために、規定に従わない文書を処理するための広範な合意も存在する。

  また、

  * 一連のトークン分析の結果が同一のものであれば、その文書の振る舞いはまったく同一になる。

  は、単に文脈自由文法(か正則文法か……SGMLってどうなのかな)であるという意味でしょうか？　それとも、単にトークンの超変数が同じくなるようなデータ(スペースとタブが例に上げられていますが)であれば、同一の処理をしろという意味なんでしょうか。
• glyphsって字体で良いんでしたっけ？
• 訳語変更
  • コード位置(code position) を文字コード番号に。
  • 提出(submit)を送信に。
  • 問い合わせフォーム(Query Forms)を照会に？
• HTMLはSGMLのアプリケーションである、というあたりを、HTMLはSGMLの適用例の一つである、としてみました。うとで思いましたが、「実例」としたほうが良いのかも。
• 1.イントロダクション(Introduction)

  Hypertext Markup Language(HTML)は、ハイパーテキスト文書を作成するために使われるシンプルなマークアップ言語で、あるプラットホームから別のプラットホームへ簡単に移すことができます。

  のを

  Hypertext Markup Language(HTML)は、ハイパーテキスト文書を作成するために使われるシンプルなマークアップ言語で、プラットホーム間で簡単に移すことができる。

  　と変えようという話があったのですが、これでも、結局はわかりにくいように思います。ここで言いたいのは「どのようなコンピュータ環境でも利用できる」というデータの可搬性のことだと思いますが……。そこまで意訳するのはまずいかな？
• 概要(Abstract)

  HTMLは1990年からワールドワイドウェブ(WWW)の全体的な情報の先駆けとして 利用されています。

  を

  HTMLは世界的に情報を発進するために1990年からワールドワイドウェブ(WWW)で 利用されています。

  と変えてみましたけど、やっぱりまだしっくりこない……。
• 1.1.ねらい(Scope)

  この文書ではHTML2.0を定義している。HTML2.0はより以前の非公式な規格書 とは区別されている。

  2.0という番号にしたのは、旧来の非公式な規格と区別するためという意味でしょうか？
• 1.2.3.ユーザーエージェント(User Agents)

  HTML文書内で指定された入力フォームを表示して、入力値を情報サービスへの要求として送信する(送信しようと試みる)ことができる。

• typical

  例示(typical)

  典型的な処理については、いくつかの例が示してあります。これは守る必要があるわけではない仕様ですが、設計者へのガイドとして、また各要素がどのような意味であるかを利用者に説明する補助として存在します。

  と私は解釈しているのですが……。
• 5.2.5.関連するメタ情報：META (Associated Meta-information: META)

  各々の<META>>要素は名称と値(name/value)の組み合わせを明示します。もし同じ名称で複数のMETA要素を使用する場合、複合的な内容――コンマで区切られたリストで表現されます――がその名称に結びつけられる。

  かなぁ？
• 4.2.2.慣例的な改行の表現(Conventional Representation of Newlines)

  テキスト実体は一連のレコード(a sequence of records)であり、レコード開 始記号により始まりレコード終了記号により終わる(それぞれの文字コード番 号は10と13です)、とSGMLでは定めています([SGML]のセクション7.6.1,"Record Boundaries")。

  [MIME]では、`text/*'のタイプの中身は一連の行であり、CRLF、つまり文字コー ド番号13と10で区切られると定められています。

  実際にHTML文書で、文書のソースの慣習に依存した行末の扱いが伝えられ表わ されています。この表現とは、CRのみ、LFのみ、CRとLFの組み合わせというも のです。そのためにデータをデコードする際にテキスト実体のレコード開始お よび終了の記号を落とすことがあります。

  失ったレコード開始および終了の記号をHTMLユーザーエージェントが推測する ようにすることを推奨します。

  HTMLユーザーエージェントは、整形済みテキストを除きすべての文章において、 いかなる種類においても単語の空白(a word space)を行末として扱うようにす るべきです。整形済みテキストでは、一般的な三つの改行表現を新たな行の開 始として扱うようにするべきです。

  を

  SGMLの仕様書では、テキスト実体は一連のレコードの連なりであり、レコード 開始記号で始まりレコード終了記号により終わると定めています(開始記号とは 10で、終了記号は13である)([SGML]のセクション7.6.1,"Record Boundaries")

  また[MIME]の仕様書では、`text/*'で示されるタイプのデータの本体は行の連 なりであり、CRLF、つまり文字コード番号13と10で区切られると定められてい ます。

  しかし実際には、HTML文書では元文書の(制作環境の)慣習に依存した方法で行 末が伝送され、表現されることがよくあります。この表現とは、CRのみ、LFの み、CRとLFの組み合わせといったものです。このため、データをデコードする 際にテキスト実体のレコード開始および終了の記号を判別し損ねることがあり ます。

  このあいまいさが、HTMLユーザーエージェントがレコード開始および終了の記 号を誤判定する原因となっています。

  HTMLユーザーエージェントは、整形済みテキストを除いたすべての文章におい て、行末を単語区切りの空白(a word space)と同様に扱うべきです。また整形 済みテキストにおいては、一般的な三種の改行表現のいずれであっても新たな 行の開始として扱うべきです。

• パラメータ、ユーザー、メーラー、サーバ、ヘッダなどの語尾の統一をどうしよう。
• 頂いたうち未検討の材料

  > 5.6.5.定義型リスト：DL,DT,DD (Definition List: DL, DT, DD)
  > 
  > 定義型リストは、用語とそれに対応する定義のリストです。一般に用語が左揃えで
  > 並び、定義はその用語の次にインデントした形で表示されます。
  > 
  要素の中身は一連の
  要素、そして／あるいは
  要素で、普通は組で使わ
  > れます。複数の
  要素が一つの
  要素と組になることもあるかもしれません。
  > 文書には複数の連続した
  要素を含めるべきではありません。
  >         ^^^^^^^^^^^^^
  > --「複数の」はなくてもいいのでは--
  > 
  > 
  > 
  > 5.10.イメージ：IMG (Image: IMG)
  > -------------------------------
  > 
  > ALT
  >     、例えば制限されていたりユーザーの状態が原因で、参照される画像リソースの
  > 代わりに使用されるテキストを指定します。
  > 
  > --処理上の問題や，ユーザーの好みなどによって画像を表示しない時に--
  > 
  > 
  > 
  > 6.文字、単語、段落(Characters, Words, and Paragraphs)
  > =====================================================
  > 
  > 一連の単語は改行された段落としての文字組です。
  >                        --として表示される--
  > 
  > 
  > 
  > 7.5.質問とインデックス(Queries and Indexes)
  > -------------------------------------------
  > 要素はハイパーリンクのセットです。ユーザーエージェントにキーワードを与
  > えることでハイパーリンクを選択することができます。ユーザーエージェントは、
  > ベースURIに`?'とキーワードをつけたヘッドURIを解析します。キーワードは
  > [URL]によって外され、`+'記号により加えられます。例えば文書が以下のマーク
  > 
  >          --エスケープされ，結合される--
  > 
  > 
  > 
  > 7.6.イメージマップ(Image Maps)
  > ------------------------------
  > もし要素にISMAP属性があれば、その要素はHREF属性付き要素に
  > 含まれなければなりません。この構成はハイパーリンクのセットを表わします。
  > ユーザーは画像のピクセルを指定することでハイパーリンクを指定することが
  >                                 --セットの中からリンクを指定することが--
  > 
  > 
  > 8.1.2.5.ピクセル画像：INPUT TYPE=IMAGE (Image Pixel: INPUT TYPE=IMAGE)
  > 
  > NAME属性は別の入力フィールドのために必要です。SRC属性は必要で、ALIGN属性は
  > 
  > --他の入力フィールドと同様に--
  > 
  > 
  > 
  > 8.1.3.選択：SELECT (Selection: SELECT)
  > 
  > SELECTED属性がどの要素にも存在しない場合には、
  > 初期状態は最初に選択されたオプションになります。
  > 
  > --初期状態では，最初のオプションが選択される--
  > 
  > 
  > 
  > 8.1.3.1.オプション：OPTION (Option: OPTION)
  > 
  > Option要素はSelect要素の中でのみ存在します。一つを選択するもので、
  >                                          --一つの項目を--
  > 
  > 
  > 8.2.1.form-urlencoded メディアタイプ(The form-urlencoded Media Type)
  > 
  >      1.フォームフィールドの名称と値はまぬがれます：空白文字は`+'に置き換えら
  >           --フォームフィールドは以下のようにエスケープされる--
  > 
  >      2.フィールドは文書に現われる順番に、`='により値と名称を区別し、`&'により
  >         ほかの組み合わせと区別して並べられます。
  >       --名前と値の組は = で区切られ，組どうしは & で区切られて並べられる--
  > 
  > 特に選択されていないラジオボタンやチェックボックスは符号化されたデータには
  > 現われませんが、VALUE属性を持つ隠しフィールドは現われます。
  > --特に，符号化データに含まれないが--
  > 
  >               注 : 問い合わせフォーム提出からのURIは通常のハイパーリンクのアン
  > カー形式として使用できます。不運なことに、`&'記号をフィールドの区切り
  > に使用することは、SGML属性値において実体参照区切り子としてその記号を
  >                                  --実体参照の区切りとして--
  > 
  > フォームの処理がidempotent(すなわちこの世界において持続的なはっきりした効果がな
  > い)ならば、フォームの方法を`GET'にするべきです。データベース検索は視覚的
  > 効果はありませんが、
  > --明らかな副作用--
  > 
  > 動作するURLがHTTPのURLで、方法が`GET'であるフォームを処理するために、ユーザーエ
  > ージェントは動作するURLに`?'とフォームデータセット――`application/x-www-form-u
  > rlencoded'フォーマットに則った――を付けたします。そしてユーザーエージェントは
  > そのURIに対してアンカーであるかのようにリンクします
  >                                     --リンクをたどる--
  > 
  > 
  > 
  > 10.セキュリティへの配慮(Security Considerations)
  > ================================================
  > 
  > フォーム提出要求で広く使われる方法――HTTPとSMTP――は、秘匿性の保証が
  > 少々必要になります。
  > --機密性をほとんど保証しない--
  1.2.2 Feature Test Entities
  
  HTML.Deprecated
   変換ソフトや編集ソフトで作成された文書には使用すべきでない
  (deprecated な)語句を含むべきではありません。
  --
   ソフトで作成された文書には，このような語句を含むべきではありません
  --
  
  
  5.2.5.関連するメタ情報：META (Associated Meta-information: META)
  
  各々の要素は名称と値(name/value)の組み合わせを明示します。もし同 じ
  名称で複数のMETA要素を使用する場合、複合的な内容――コンマで区切られ
  たリストで表現されます――がその名称に結びつけられる。
  --
   もし同じ名前の META 要素が複数ある場合には，
   それぞれの値をコンマで区切られたリストが
                         区切ったリストが
                         区切ってリストにしたものが
   その名前の値として用いられる
  --
  
  
  3.1 SGML Documents
  DTD文法の最初の記号はHTMLで、それにより`-//IETF//DTD HTML 2.0//EN'
  (9.1.「HTML　DTD」)により定義される仕様書として与えられます。終端まで
  は以下のように構成されます。
  --
   以上の(上の)終端記号は次のように構文解析される
  --
  
  
  5.2.5 Associated Meta-information: META
  
  HTTPサーバは文書のを読み取り、HTTP-EQUIV属性の値で定めたいかなる
  要素にも一致するようにヘッダ部分を作成するでしょう。
  
  --
  HTTP サーバーは文書の HEAD 部を読み，HTTP-EQUIV 属性用に値を
   定めている各要素に対応するヘッダフィールドを生成してもよい
  ＃うーん，いまいち
  --
  
  
  5.5.2 Preformatted text: PRE
  
    * アンカー要素と語句マークアップは有効である
  --
   アンカー要素と語句マークアップを使ってもよい
  --
  
  
  
  5.5.4.引用：BLOCKQUATE (Block Quate: BLOCKQUATE)
                     ^            ^           ^
                     O            o           O
  一般的には左右を少しインデントし、イタリック体で表示
  (あるいはどちらかのみ)されます。また引用部分の前後にスペース
  を空けます。
  --
   インデントするか，イタリックを使うか，またはその両方の方法で
   表示される
  --
  
  Single-fontでは、左のマージンに大なり記号(>)のようなグラフィック
  記号を縦に並べるという、インターネットメールでの引用のスタイル
  を反映するかもしれません。
  --
   一つのフォントしか使えない場合，インターネットでのメールの引用
   スタイルを reflect してもよい
              参考にする？
  --
  
  
  5.7.2.表示型要素(Typographic Elements)
  
  表示型要素はマークされたテキストの形式を定義するのに使用します。
  
  語法的要素の一般的な表示はユーザーエージェントにより変化します。
  もし具体的な表示が必要なら――例えば「イタリックの部分は必須」
  という明確なテキスト属性を参照する場合――、表示型要素は意図
  した表示を確実に可能にします。
  --
   例えば，「イタリックの部分は必須」というように，テキスト属性を
   明示(指定)したい場合，typographic 要素を用いれば，可能な限り
   指定した通りに表示させることができる．
   (typographic 要素を，指定した通りに表示させるために使うことができる)
  --
  
  
  7.5.質問とインデックス(Queries and Indexes)
  -------------------------------------------
  ユーザーエージェントは、ベースURIに`?'とキーワードをつけた
  ヘッドURIを解析します。キーワードは[URL]によって外され、`+'記号に
  より加えられます。
  
  --
   ユーザーエージェントは，
   ベースURI(の後)に`?'とキーワードを付け，ヘッド URI を生成する．
                                                        ^^^^
   キーワードは[URL]に従ってエスケープされ，`+'記号で連結される
  --
  
  
  
  
  14.提案された実体(Proposed Entities)
  ====================================
  "Added Latin 1"実体セットは、[ISO-8859-1]における非ASCII文字の
  サブセット、すなわちアクセント付き文字に名称付き
  実体を提供するだけです。すべてのISO 8859-1記号が象徴的に参照
  されるようになるために以下の実体をサポートさせるべきです。
  
  --
  名前だけで参照できるように
  --