正則なXML バージョン 1.1

提供：STUDIO DDT ONLINE
2010年3月22日 (月) 23:18時点におけるStudioddtonlinewiki (トーク | 投稿記録)による版 (→‎用途)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
ナビゲーションに移動検索に移動

この文書はW3CがW3C勧告として公開している仕様書"Canonical XML Version 1.1"をSTUDIO DDT ONLINEが学習目的で日本語に翻訳したものです。正式な仕様書は英語版のみであり、この日本語訳は参考にすぎません。

この文書には翻訳上の誤りが含まれるかもしれません。STUDIO DDT ONLINEは翻訳の正確性を保証しません。

この文書のレイアウトはMediaWikiの記法に依存するため、オリジナルの文書とは文書構成、HTMLのセマンティクス、見栄え等が異なります。

W3C勧告2008年5月2日

このバージョン
http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/
最新のバージョン
http://www.w3.org/TR/xml-c14n11/
以前のバージョン
http://www.w3.org/TR/2008/PR-xml-c14n11-20080129/
編者
John Boyer, IBM (元PureEdge Solutions Inc.) Version 1.0
Glenn Marcy, IBM

この文書に含まれる規定の修正箇所はエラッタを参照してください。

また、翻訳一覧も参考まで。

著作権© 2008 W3C®（マサチューセッツ工科大学、欧州情報科学数学研究コンソーシアム、慶應義塾大学）により、全ての権利が留保される。W3Cの免責、商標、文書利用規定が適用される。

この翻訳文の著作権はSTUDIO DDT ONLINEおよびサイト管理者が保持しています。この翻訳文の利用などについては免責事項を参照してください。ただし、原文のライセンス内容によっては免責事項よりも原文のライセンスが優先されます。


概要[編集]

正則なXML 1.1は、文書部分集合の正則化を実施するときのXML名前空間の属性継承に関する問題を解決するために正則なXML 1.0を見直したものであり、xml:idを継承しないという要求と、xml:base URIを厳密に処理するという要求を含む。

あらゆるXML文書は、アプリケーションコンテキスト内部で論理的に同等だが、XML 1.0 [XML] および XML名前空間 1.0 [Name] によって許された構文変化に基づく物理的表現が異なる一連のXML文書群の一部である。この仕様書は、許容変化から成るXML文書の、正則形式の物理的表現生成方法を記述する。まれな例外事項と思われる制限を除けば、二つの文書が同じ正則形式を持つ場合、それらは所定のアプリケーションコンテキスト内で論理的に等価である。二つの文書が異なった正則形式を持っても、一般的でないXML仕様を適用したアプリケーション独自の同義規則に基づく所定のコンテキスト内で同義かもしれないことに留意せよ。

正則なXML 1.1は、XML 1.0に適用され、XPath 1.0データモデルの単語によって定義されている。XML 1.1のためには定義されていない。

この文書の位置づけ[編集]

今節では公開時におけるこの文書の位置づけを説明する。他の文書がこの文書に取って代わるかもしれない。この技術報告書の最新版と現在のW3C発行物の一覧は、http://www.w3.org/TR/にあるW3C技術報告書一覧から参照できる。

これはW3C勧告である。

この文書はW3C会員、ソフトウェア開発者、他のW3Cグループ関係者によって評価済みで、管理者によりW3C勧告として支持されている。それは完成した文書であり、参照資料として使われたり、他の文書から引用されても良い。勧告作成におけるW3Cの役割は、仕様を注目させ、その広範な展開を促進することにある。これによってウェブにおける機能性と相互運用性がより高まる。

この文書に対するコメントはwww-xml-canonicalization-comments@w3.orgに送信すれば、自動的に共通の電子メール一覧に保存される。

この翻訳に関する誤りは、サイト管理者にお伝えください。

実装報告書では、様々な勧告候補による実装での評価を詳しく述べている。この実装報告書が、勧告候補に反して実装された結果を、勧告候補の期間中に挙げられた問題点に基づく結果として反映し、後にこの勧告の文言に反映されたことにに注目すべきである。

この文書はW3CのXML活動の一部である、W3CのXMLコアワーキンググループによって提供されている。この文書の編者はXMLコアワーキンググループの会員と、電子署名団体から招かれた専門家である。

この文書は2004年2月5日版W3C特許方針の下で活動中のグループによって作成された。W3Cは、グループの成果物に関連することでもたらされたあらゆる特許開示の公的なリストを維持管理しており、また、そのリストは特許を開示するための方法を含んでいる。基本請求権があると思う特許について実際の知識をもつ個人は、W3C特許方針の6節に従った情報を公開しなければならない。

この仕様の英語版が唯一の規定版である。

導入[編集]

XML 1.0勧告 [XML]は、XML文書と呼ばれる情報資源類の構文を規定する。XML名前空間 1.0勧告 [Name]は、XML文書のための追加の構文と意味論の仕様を規定する。そこで、物理的表現の点で異なるものの、多くの利用目的のために等価なXML文書が可能になる。例えば、実体構造や、属性順序、文字符号化の点でそれらは異なるかもしれない。この仕様の最終目的は、XML 1.0とXML名前空間 1.0で許された変形を除いて、 二つの文書が同一かどうかを、またはアプリケーションが文書を変化させないかどうかを判断する方法を確立することにある。

正則なXML 1.1は、文書部分集合を正則化するときのXML名前空間属性の継承に関する問題を解決するために正則なXML 1.0 [C14N10]を見直したものであり、xml:idを継承しないという要求と、xml:base URIを厳密に処理するという要求を含む。正則なXML 1.0に対する正則なXML 1.1の関係にかかるさらなる議論については、[C14N-Issues]と[DSig-Usage]上でのワーキンググループノートを参照せよ。

正則なXML 1.1は、XML 1.0に適用され、XPath 1.0データモデルの単語によって定義されている。XML 1.1のためには定義されていない。

用語[編集]

この文書において"しなければならない[MUST]"、"してはならない[MUST NOT]"、"要求されている[REQUIRED]"、"することになる[SHALL]"、"することはない[SHALL NOT]"、"する必要がある[SHOULD]"、"しないほうがよい[SHOULD NOT]"、"推奨される[RECOMMENDED]"、"してもよい[MAY]"、"選択できる[OPTIONAL]"といった単語は RFC 2119 [Keywords]に記述されているように解するものとする。

この翻訳では、必ずしも上記のように翻訳されていませんが、原文に明記されている箇所では、翻訳でも明らかであるようにしています。

有修飾名（Qname）の定義はXML名前空間勧告 [Name]を見よ。

文書部分集合（document subset）とは、文書内の全ノードを含まないかもしれないノード集合によって示されたXML文書の一部である。

XML文書の正則形式（canonical form）とは、この仕様書に示された方法で作成された文書の物理的表現のことである。変更点は要約すると以下の通り。

  • 文書は、[UTF-8]で符号化される
  • 改行は、構文分析前の入力時に#xAへ正規化される
  • 属性値は、あたかも妥当性を検証する処理装置によって正規化されたように、正規化される
  • 文字と解析対象実体参照が、置き換えられる
  • CDATAセクションは、文字内容と置き換えられる
  • XML宣言と文書型宣言は、削除される
  • 空要素は、開始・終了タグの対に変換する
  • 文書要素外部と、開始タグおよび終了タグ内部の空白文字は、正規化される
  • 文字内容内のすべての空白は、確保される（行末正規化中に削除された文字を除く）
  • 属性値の区切り文字は、引用符（ダブルクォート）と定める
  • 属性値と文字内容の内の特殊文字は、文字参照によって置き換えられる
  • 余分な名前空間宣言は、各要素から削除される
  • 既定属性が、各要素に追加される
  • 辞書式順序が、各要素の名前空間宣言と属性に課される
  • xml:base属性の整理（fixup）が行われる

正則なXML（canonical XML）という用語は、正則形式に則ったXMLのことである。XML正則化法（XML canonicalization method）とは、所定のXML文書または文書部分集合の正則形式を生成する、この仕様によって定められたアルゴリズムのことである。XML正則化（XML canonicalization）という用語は、XML文書または文書部分集合へXML正則化法を適用する処理のことである。

XPath 1.0勧告 [XPath]は、ノード集合（node-set）という用語を定義し、様々な種類（要素、属性、名前空間、文章、注釈、処理命令、およびルート）のノードの集合のような、入力されたXML文書をあらわすデータモデルを規定する。ノードは、式の評価に基づいたノード集合から除かれるか、あるいは含まれる。 この仕様書内において、ノード集合は、各ノードが正則形式として与えられるべきかどうかを直接に示すものである（ここでは、厳密に数学的集合として使われている）。たとえ親ノードがノード集合に含まれても、集合から除かれたノードは生成された正則形式として表されない。しかし、除かれたノードは、なお子孫の表示に影響を与えるかもしれない（例えば、子孫の名前空間コンテキストの増大、あるいはxml:baseを介した基底URIの提供によって)。

用途[編集]

XML 1.0勧告 [XML]とXML名前空間 1.0勧告 [Names]が、等価な情報を表すための複合構文法を定めてから、XMLアプリケーションでは文書の情報内容に影響を与えない程度の違いを持つ傾向がある。XML正則化は、文書または文書部分集合が変化しているかどうかテストするための能力を要求されるアプリケーションに有用なようにデザインされており、アプリケーション処理前後の文書の正則形式を比較することによってなされる。

例を挙げると、XML文書や文書部分集合の正則形式を用いたデジタル署名では、XML 1.0とXML名前空間によって論理的に等価であるとする変化が定められているため、原本の物理的表現の変化に依らない署名ダイジェスト演算を可能にする。署名作成中、ダイジェストは文書の正則形式を元に計算される。そのとき文書は依拠当事者に委ねられ、文書を読み込んで正則形式からダイジェストを計算することによって署名を認証する。署名と依拠当事者によって計算されたダイジェストの等価さは、（計算済み正則形式を用いた正則形式の等価さゆえに）文書の情報内容が署名されてから改竄されていないことを保証する。

註: 実装の要件で述べられていない上、正式にこの件について明らかにしていないが、この仕様書に従っている文書を正則化して得た文字列を構文解析して再び正則化した場合に、2回目の正則化によって得られた文字列が最初の正則化で得られたそれと同一になるだろうことが、この仕様書の意図である。

制限[編集]

二つのXML文書は、所定のアプリケーションコンテキスト内部で論理的に等価であるにもかかわらず、異なる情報内容を持ち得る。二つのXML文書は、各々の正則形式が同一であれば等価（この節で示す制限は別にして）であるが、正則形式が同一である時かつその時に限り、二つのXML文書が等価であるような方法を確立することが、この仕様の目指すところではない。一つには、重要でない空白や等価なデータ（例えば、<color>black</color> と <color>rgb(0,0,0)</color>）に左右されるアプリケーション仕様規定の問題があり、そのような方法は実現不可能だ。他のW3C勧告や作業草案によって確立された等価さが、やはり存在する。これらの付加された等価規定を説明することは、この仕様の範囲を超えている。それらはアプリケーションによって適用されても良いし、さもなくば将来の仕様書の題目となるかもしれない。

XML文書の正則形式はアプリケーションコンテキスト内部で全面的には運用し得ないが、そのような状況はまれである。文書の正則形式と、文書の正則形式の正則形式が等価であるので、この問題は特定のアプリケーションでは懸念事項であるかもしれない。例を挙げると、デジタル署名アプリケーションでは、正則形式がダイジェスト計算の変更なき原本を代替できることが可能なので、処理中の原本かどうかを、もしくは、処理中でない署名済みの正則形式かどうかを、証明できない。しかし、セキュリティリスクは後述するまれな環境でしか起こらないし、すべて無効とすることができるか、デジタル署名作成より前に発覚する。

問題は、データモデルで利用できない付帯情報の脱落が原因で起こる。すなわち、

  1. 基底URI（base URI）、特に外部一般解析対象実体参照を置き換えたテキストに由来するもの
  2. 記法（notation）、および外部解析対象外実体参照
  3. 文書型宣言内の属性型

一つ目の事例の場合、相対URI [URI]を含む文書は、適切な基底URIを定める固有URIからアクセスしたときのみ、操作するように留意せよ。加えて、文書が相対URIを含む内容を参照する外部一般解析対象実体を含む場合、相対URIは正則形式の操作上にない。正則形式は内部内容の実体参照を置き換える（従って、暗黙のうちに内容の標準基底URIへ変更する）。これらの問題は通常、アプリケーションにxml:base属性 [XBase]のサポートを追加し、外部実体の全最上位要素と文書要素へ適切なxml:base属性を追加することで解決される。さらに、アプリケーションは時折、正則形式の必要性に先立って相対URIを解消する機会を得る。例えば、デジタル署名アプリケーションにおいて、ある文書は時折、署名作成に先立って読み出しと処理をされる。その処理は、相対URIを絶対URIへ変換済みの新規文書を作成する必要があり[SHOULD]、その結果、新しい文書へのあらゆるセキュリティリスクを軽減することになる。

二つ目の事例の場合、外部解析対象外実体参照の脱落とアプリケーション固有の記法により、正則形式がこのメカニズム経由の解析対象外データを組み込むXML文書を適切に区別することができなくなる。現在、ほとんどのXMLプロセッサは、文書型宣言、記法を切り捨てた文書型宣言、URIに結合する実体、属性値を実体名に限定する属性型らを切り捨てるので、これはまさに稀なケースである。二つ以上のXMLプロセッサにさらされざるをえない文書のために、XMLの設計では、通常、属性値にはURIを用いた解析対象外データの参照を表している。

三つ目の事例の場合、属性型の脱落は、型に依存する異なった方法の正則形式に影響を及ぼす可能性がある。xml:id属性を除いて、ID型の属性がID属性でなくなるので、あらゆるid()関数を用いた正則形式を参照するXPath評価式は、処理を中断してしまう。ENTITYおよびENTITIES属性型では、この事例でなく、二番目の事例にあたる。ID、IDREF、IDREFS、NMTOKEN、NMTOKENS、NOTATION型と列挙型の属性では、正則形式がアプリケーション処理中に原本を置換する場合、正則形式が次に属性値の変更を試行する間、適切に律則されない。アプリケーションは、さらなるXML処理で正則形式を使用する前に、適切な文書型宣言を先頭に追加することによって、この事例の問題を回避することができる。属性リストはたいてい標準の外部DTDサブセットから得られるので、おそらく簡単な作業であるし、外部DTDサブセット中のあらゆる実体と記法の宣言も、アプリケーション初期化情報から構成され、内部DTDサブセットへ追加される。

とはいえ、これらの制限は難しいことではなく、例えば、現在W3Cで開発中のXML情報セット[Infoset]を元に作成されている新しい版のXPathがあれば、XML正則化の将来版で解決可能なことである。

XML正則化[編集]

データモデル[編集]

XPath 1.0勧告 [XPath]で定義されたデータモデルは、入力されたXML文書や文書部分集合を表すものである。データモデルの実装は必ずしもXPathの実装に基づく必要はないが、基づくべきである[SHOULD]。XML正則化はノード集合のXPath定義規則に規定され、実装では同一の結果を提供しなければならない[MUST]。

XML正則化法の第一引数は、XPathノード集合か、バイトストリームのどちらか一方である。仮にバイトストリームであれば、整形式XML文書を含まねばならない。実装は、バイトストリーム入力をサポートしなければならず[MUST]、ノード集合入力経由の文書部分集合フィーチャもまたサポートするべきである[SHOULD]。 XPathノード集合の用語で正則化を記述するため、この節ではバイトストリームがXPathノード集合に変換済みであるように記述する。

正誤表E11-02を折り込み済みです。

XML正則化法の第二引数は、注釈がXML正則化法による正則形式出力に含まれるべきかどうか指示する真偽値である。入力されたノード集合内の注釈ノードに該当する注釈を正則形式が含む場合、結果を注釈つきの正則なXMLと呼ぶ。 XPathデータモデルでは、注釈を文書型宣言内部の注釈ノードを作成しないことに留意せよ。実装は、入力文書もしくは文書部分集合に現れるすべての注釈を排除した正則なXMLを提供可能であることが要求される[REQUIRED]。注釈つきの正則なXMLのサポートは、推奨される[RECOMENDED]。

XML文書をノード集合に変換せねばならないとしたら、 XPathは、XMLプロセッサが十分に文書を表す、XPathデータモデルのノードを作成するものであることを要求する[REQUIRES]。 XMLプロセッサは、次のリストにある作業を順番に実行する。

  1. 改行の正規化
  2. 属性値の正規化
  3. CDATAセクションの文字内容への置き換え
  4. 文字参照と解析対象実体参照の解決

バイトストリーム入力は整形式（well-formed）XML文書を含まねばならない[MUST]が、 妥当（valid）である必要はない。しかし、属性値正規化と実体参照解決は、 妥当性を検証するXMLプロセッサによる振る舞いに従って実行されねばならない[MUST]。むしろ、既定の（定義されていないが、AttValueを伴うATTLISTと宣言されている）属性ノードは、同じ要素に作られたほうが良い。このように、たとえ文書型宣言が正則形式で保持されていなくとも、文書型宣言の宣言は正則形式の作成を補助するものである。

XPathデータモデルはUCS文字を使ったデータで表現する。実装は、UTF-8とUTF-16および、UCS文字領域への変換をサポートしなければならない[MUST]。UTF-16について、行頭のバイトオーダーマークは符号化の結果として扱われ、UCS文字データ（UTF-16データ内に現れるゼロ幅非分割空白（zero width non-breaking space）は削除されない）から排除される [UTF-16, 3.2節]。ISO-8859-1符号化対応が推奨され[RECOMENDED]、その他すべての文字符号化の対応は選択できる[OPTIONAL]。

ルート文書要素内のすべての空白文字は、保護されねばならない[MUST] （行末正規化によって削除されたすべての#xD文字を除く）。これは実体外部の全空白文字を含む。ルート文書要素外の空白文字は、放棄されねばならない[MUST]。

XPathデータモデルでは、次のノード型が存在する。すなわち、ルート、要素、注釈、処理命令、テキスト、属性と名前空間である。処理命令ノードと文書要素外（および文書型宣言外）の情報を表現する注釈ノードを子に持つ、一つのルートノードが存在する。ルートノードは、最上位の文書要素を表す一つの要素ノードもまた持つ。各要素ノードは、要素、テキスト、処理命令、注釈型の子ノードを持つことができる。要素に連携した属性と名前空間は、要素の子ノードになるとみなさないが、要素のattribute軸（axis）およびnamespace軸の中に包括されることにより、要素に連携される。attribute軸およびnamespace軸が、原本内の要素開始タグに現れるテキストにそのまま相当しないかもしれない事に留意せよ。

註: ある要素は、規定属性を表すノードと同様に、自身の開始タグに現れる名前空間属性宣言を明らかにしない属性ノードを持つ。

XPathデータモデルのおかげで、XML正則化は名前空間を扱える [Names]が、それゆえに名前空間接頭辞の書き換えを用いて名前空間の等価さを説明しないし、できない（第4節の説明を見よ）。XPathデータモデルでは、それぞれの要素や属性は、name()関数によって返された、アプリケーションの裁量次第では原本にある有修飾名と同じ名前を持つ。XML正則化では、XMLプロセッサが原本内で与えられ得る要素の有修飾名の十分な情報を保持することを要求する[REQUIRES]。

註: 既定名前空間が空でなく、かつ、接頭辞xmlの宣言ならば、要素Eはあらゆる名前空間宣言と同様に、自身の名前空間宣言がEの宣言を上書きしていないその祖先によって明言される名前空間ノードを持つ。

註: この仕様書は次のような相対名前空間URIに反する最新のXML無条件決議に対応する。すなわち、XML正則化の実装では、相対名前空間URIを含む文書の操作失敗を報告しなくてはならない[MUST]。XML正則化では、相対URIを絶対URIへ変換するXMLパーサを実装してはならない[MUST NOT]。

文字内容は、XPathデータモデルではテキストノードとして表される。すべての連続した文字は、単独のテキストノードに定められる。その上、テキストノードの文字はUCS文字範囲内で表現される。XML正則化法は文字モデル正規化を行わない（第4節の説明を見よ）が、XMLプロセッサは、UCSベース（現在、UCSベースの符号化とは、UTF-8、UTF-16、UTF-16BE、UTF-16LE、UCS-2、UCS-4を含む）でないあらゆる符号化からUCS文字範囲内へXML文書を変換する際、Unicode正規化形式C [NFC, NFC-Corrigendum]を使うよう要求された[REQUIRED]XPathデータモデル入力に備える慣わしであった。

XML正則化がXPathノード集合を正則形式へ変換した後、第一引数は、XPathノード集合にならねばならない[MUST]か、前述したXPathノードを生成することなくXML処理の実行によって、バイトストリームからXPathノード集合へ変換されねばならない[MUST]。その時、XPath評価コンテキスト初期設定は以下の通り。

  • コンテキストノードは、入力されたXML文書のルートノードを初期化
  • コンテキスト位置は、1へ初期化
  • コンテキストサイズは、1へ初期化
  • XPath勧告と一致するあらゆる関数ライブラリ
  • 一連の変数束縛は空
  • 一連の名前空間宣言は空

そして、次の既定評価式の評価。すなわち、

注釈引数値 既定XPath評価式
注釈なし（偽） 
(//. | //@* | //namespace::*)[not(self::comment())]
注釈あり（真） 
(//. | //@* | //namespace::*)

この表の評価式が、XML文書のすべてのノードを含むノード集合を生成する（注釈引数値が偽の場合は、注釈を排除する）。

入力がXPathノード集合の場合、ノード集合は正則形式になる全ノードを明確に含まなくてはならない。例えば、XPath評価式id("E")の結果は "E" のID属性値を伴う要素と一致するノードのみを含むノード集合になる。子孫ノード、属性ノード、名前空間ノードが集合内にないので、正則形式は、内部内容抜きで、属性と名前空間宣言の脱落した、単独の要素の開始タグと終了タグから成る。第3.7節で、内部内容、属性、名前空間宣言に加えて、一体になった要素の直列化の仕方について例示する。

文書順[編集]

XPathノード集合は順不同であると定義されているが、XPath 1.0勧告 [XPath]は、一般実体展開後に文書のXML表現中に生じる各ノードのXML表現の第一文字目の順番を、文書順（document order）という用語で定める。ただし、アプリケーション依存の文書順である名前空間ノードと属性ノードを除く。

XML正則化法では、後述する各要素の名前空間ノードと属性ノード上での追加の文書順規則を負うことによって、ノード集合を処理する。すなわち、

  • ある要素の名前空間ノードと属性ノードは、その要素より大きく、要素の子ノードより小さい文書順位置を保持する
  • 名前空間ノードは、属性ノードより小さい文書順位置を保持する
  • ある要素の名前空間ノードは、局所名（local name）によって辞書順に従って並び替えられる（一つの例外は、既定名前空間ノードが局所名を持たないため、辞書順では最も小さいこと）
  • ある要素の属性ノードは、優先キーとして名前空間URIを、代替キーとして局所名をもとに辞書順に並び替えられる（空の名前空間URIは、辞書順では最も小さい）

アルファベット順に最小から最大まで文字を順序づける辞書式比較は、UTF-8に基づく辞書式順序と等価なUCS符号位置値に基づく。

処理モデル[編集]

XPathノード集合は、昇順な文書順中のノード集合内にある各ノードの代わりにUCS文字列表現を生成することにより、バイトストリームや正則形式に変換され、その結果（行頭のバイトオーダーマークなしの）UTF-8へ符号化する。どのノードも複数回処理されない。要素ノードEの処理とは、Eの祖先である全ノード集合の処理を含むことに留意せよ。従って、Eのテキスト表現が生成されると直ちに、Eと、そして全てのEの祖先ノードらは、ノード集合から削除される（または、文書順でそのノード集合の次ノードが処理中とならないように、ある論理的に等価な処理が生じる）。しかし、要素ノードはその子ノードが処理されるまでノード集合から削除されないことに留意せよ。

ノードの処理結果は、そのノード型とそのノードがノード集合内に存在しないかどうかに依存する。ノードがノード集合内のものでない場合、（要素の）namespace軸とattribute軸、および、（要素とルートノードの）子ノードの処理結果を除き、ノードの代わりのテキストは生成されない。ノードがノード集合内のものである場合、そのノードのnamespace軸とattribute軸、および、子ノードの処理によって生成されたテキストが加わった正則形式中に、ノードに相当するテキストが生成される。

註: ノード集合は、ノードの集合のように取り扱われ、サブツリーのリストのようには取り扱われない。名前空間、属性、内容を含む要素の正則化のために、ノード集合は実質的に、文書の一部に対応する全てのノードを含まねばならず、要素ノードだけを含んではならない。

ノードの代わりに生成されるテキストは、ノード型に依存し、次のリストの通り。すなわち、

  • ルートノード- ルートノードは、最上位文書要素の親である。各子ノードの処理結果は、文書順内のノード集合中にある。ルートノードは、バイトオーダーマーク、XML宣言、もしくは文書型宣言内部からのあらゆるものを生成しない。
  • 要素ノード- 要素がノード集合内にない時の結果は、namespace軸、次にattribute軸、次に（文書順内の）ノード集合内にある要素の子ノードの処理によって求められる。要素がノード集合内にある場合の結果は、始め山括弧 (<)と、有修飾名（QName）と、namespace軸の処理結果と、attribute軸の処理結果と、終わり山括弧 (>)と、（文書順内の）ノード集合内の要素の子ノードの処理結果と、始め山括弧と、スラッシュと、要素の修飾された名前と、終わり山括弧である。
    • namespace軸- 辞書式順序（昇順）のノード集合内の軸の中の名前空間ノードのみを含むリストLについて考える。Lの処理開始時、第一のノードが既定名前空間ノード（名前空間URIと局所名を伴わない名前空間ノード）でない時かつ後述する状態である場合に限り、空白文字に続いてxmlns=""を生成する。後述する状態とはすなわち、
      • 要素E自身の軸がノード集合内にある
      • ノード集合内のEに最も近い祖先が、ノード集合内の既定名前空間を持つ（XPathでは、既定名前空間ノードは常に空でない値を持つ）
      後者の状態では、既定名前空間が空で、空でない既定名前空間をもつ正則形式内の直接の親をもつ場合、要素はxmlns=""のみを受け取りし後、正則形式内の必要でないxmlns=""の発生を排除する。Lの処理終了時、局所名xmlの名前空間の排除を除き、L内の全名前空間ノードは単純に処理する。局所名xmlの文字列値がhttp://www.w3.org/XML/1998/namespaceの場合、局所名xmlは接頭辞xmlを定義する。
    • attribute軸- 辞書式順序（昇順）に、要素のattribute軸内とノード集合内にある各ノードを処理する。
  • 名前空間ノード- ノード集合内のノードの親要素に最も近い祖先要素が、ノード集合内にNと同じ局所名と値の名前空間ノードをもつ場合、名前空間ノードNは無視される。そうでなければ、既定名前空間ノードがある場合を除いて、属性ノードと同じ方法で名前空間ノードNを処理する。既定名前空間ノードのためには、空の局所名の代わりに局所名としてxmlnsを用いる。（XPathでは、既定名前空間ノードは空のURIと局所名を持つ）。
  • 属性ノード- 結果は、空白文字と、ノードの修飾された名前と、等号と、始め引用符（ダブルクォート）と、修正された文字列値と、終わり引用符（ダブルクォート）である。ノードの文字列値は全てのアンパサンド（&）を&amp;へ、全ての始め山括弧（<）を&lt;へ、全ての引用符文字を&quot;へ、全ての空白文字#x9、#xA、#xDを文字参照へ置き換えることで修正される。文字参照はゼロの導きを伴わない大文字の16進数で書かれる（例えば、#xDは&#xD;という文字参照で表される）。
  • テキストノード- 結果は、&amp;に置き換えられた全てのアンパサンドと、&lt;に置き換えられた全ての始め山括弧（<）と、&gt;に置き換えられた全ての終わり山括弧（>）と、&#xD;に置き換えられた全ての#xD文字とを除いた、文字列値である。
  • 処理命令ノード- 結果は、処理命令開始符号（<?）と、処理命令目標ノード名と、空でない場合は先導する空白文字および文字列値と、処理命令終了符号（?>）である。文字列値が空の場合、先導する空白文字は追加されない。同様に、行末の#xAは、文書要素より小さい文書順を伴うルートノードの子である処理命令のための処理命令終了符号の後に描画され、行頭の#xAは、文書要素より大きい文書順を伴うルートノードの子である処理命令のための処理命令開始符号の後に描画される。
  • 注釈ノード- 注釈を伴わない正則なXMLを生成する場合、注釈ノードは存在しない。注釈付きの正則なXMLでは、注釈開始符号（<!--）と、ノードの文字列値と、注釈終了符号（-->）を生成する。また、行末の#xAは、文書要素より小さい文書順を伴うルートノードの子である注釈のための注釈終了符号の後に描画され、行頭の#xAは、文書要素より大きい文書順を伴うルートノードの子である注釈のための注釈開始符号の後に描画される（ルートノードの子である注釈とは、最上位文書要素と文書型宣言の外側にある注釈を表す）。

ノードの有修飾名は、名前空間接頭辞文字列が空、または、名前空間接頭辞と、コロンと、その時の要素の局所名である場合、どちらか一方の局所名になる。有修飾名の名前空間接頭辞は、入力された文書に現れるどれか一つと同じでなければならない[MUST]。

文書部分集合[編集]

あるアプリケーションでは、（標準生成されたXML文書部分集合以外に、注釈が排除されている場合に文書の厳密な部分集合となる）XML文書部分集合のための物理的表現を生成する能力を求められる。XPathに基づいたXML正則化の実装では、バイトストリームとしてよりむしろ投げ込まれるようにノード集合を受け入れることによって、少々の負荷のかかるこの機能性を備える。あるXPathノード集合が投げ込まれるように与えられて、要素の親がノード集合から排除されるとき、ある要素ノードEの処理はわずかに変更されなければならない[MUST]。XML名前空間で定義された継承可能属性の継承規程が破れることになる[SHALL][C14N-Issues]ので、ノードの 排除が必要である。

[定義:] 単純継承可能属性とは、最も単純な再定義を必要とする値を持った属性である。この再定義とは、child軸内に新たな値を与えることによってなされる。Eの祖先の一つに含まれる単純継承可能属性Aの再定義とは、要素Eの内部の属性Aeに同じ名前の値を与えることによってなされる。単純継承可能属性とは、xml:langとxml:spaceである。

ノード集合内の要素Eのattribute軸の処理方法が強化される。Eのancestor軸に沿う全要素ノードは、xml:langやxml:spaceのような、最も近いXML名前空間内の単純継承可能属性の存在を検査される（ノード集合内での有無に問わず）。この属性の一覧から、（ノード集合内での有無に問わず）Eのattribute軸にすでに存在する単純継承可能属性は削除される。その時、ノード集合に含まれるEのattribute軸のノードと、この属性一覧を辞書編集上に結合する。attribute軸を検査した結果は、この結合した属性一覧中の属性ノードを処理することによって算出される。

xml:id属性は単純継承可能属性ではないため、これら属性の処理は行われない。

xml:base属性は単純継承可能属性ではないため、単純な再定義ではなく特別な処理が要求される。それ故、Eのattribute軸の処理はよりいっそう強化される必要がある。「URI参照連結」機能とは、xml:baseを整理するために用いられ、排除されたxml:base属性からxml:base属性値を取り入れ、整理される要素のxml:base属性値を更新するものである。

xml:baseの整理は後述するように要素E上で行われる。仮に、Eがancestor軸に一連の排除された要素En･･･E1を（逆文書順で）含むノード集合の中のある要素で、E=En+1が含まれる時、（En･･･E1が、例えば3.8節の実例ではe2のように、連続して排除された要素であることに留意することは重要である）E1・・・Enのどれかが少なくとも一つのxml:base属性を持って初めて整理が行われる。そこで、X1･･･XmがE1･･･En+1のxml:base属性値であるとすると（ただし文書順、外側から内側へ、m <= n+1）、連続する値は、逆文書順で最初XmとXm-1の合成によってある一つの値に帰される。Eのxml:base属性に新しい値が与えられるまで"URI参照連結"が呼び出されて機能することにより、Xm-2などが結果となる。xml:baseが表示されてはならない[MUST NOT]場合も同様に、結果はヌル、または空（xml:base=""）となってよい。

xml:base属性を持つある要素が削除される場合のみ、このようなxml:baseの整理が行われることに留意せよ。特に、要素は存在しているにも関わらず属性が削除されている場合は機能しない。

URI参照連結機能は排除された要素からxml:base属性値を取得し、xml:base属性を更新するための値を作成するために、他の隣接して排除された値とそれを結合する。この機能を成す単純な方法はRFC 3986の第5.2.1節、第5.2.2節、第5.2.4節にあるものに後述する変更を加えたものと似ている。すなわち、

  • RFC 3986の第5.2.1節を実施する。"基底URIの事前解析"では次のように変更する。
    • 基底URI（Base）のスキーム部分は必要でない（すなわち、Base.schemeはヌルでもよい）
    • 処理より前に、末尾の".."部分を"../"部分に置き換える
  • 第5.2.4節の"ドット部分の削除"は次のように変更する
    • 先頭の"../"部分は削除しない
    • 複数の連続した"/"文字を単一の"/"文字へ置き換える
    • 末尾の".."部分へ"/"文字を付け加える
  • "ドット部分の削除"アルゴリズムは、属性値が相対パス部分となる（すなわち、パス部分が"/"文字で始まらない）成分を含む二つのxml:base属性値の組み合わせを確保するように変更される
  • RFC 3986の第5.2.2節を実施する。"参照の変形"は、Rのフラグメント部分を無効とするために次のように変更する
    • Rの解析後にR.fragment = nullとする

次に、ノード集合中のEのattribute軸の特定ノードを持つこの整理済み属性を、辞書的に結合せよ。attribute軸の検査結果は、この結合済み属性一覧中の属性ノードを処理することによって算出される

XML名前空間中のxml:base、xml:id、xml:lang、xml:space以外の属性は、通常の属性のように処理されねばならない[MUST]

次のサンプルでは"ドット部分の削除"アルゴリズムの変更点を説明する。

  • "abc/" と "../" では "" となる
  • "../" と "../" では "../../" のように連結され、 "../../" となる
  • ".." と ".." では "../../" のように連結され、 "../../" となる

最後の例では、次に示すXML文書の例から要素bとcが削除されるとき、要素d上のxml:base属性の正しい結果が"../../x"となることを図示する。 

    <a xml:base="foo/bar">
      <b xml:base="..">
        <c xml:base="..">
          <d xml:base="x">
          </d>
        </c>
      </b>
    </a>

XML正則化の例[編集]

この節の例は、正当でない処理装置が仮定され、そもそも文書型宣言が、文書内の全要素の全属性を宣言することなしに、既定の属性やさまざまな型の属性（列挙型IDのような）と同様に実体を宣言できるようになっている。その上、ある例は故意に妥当性制約に違反した要素を（それでも整形式なので）含む。

処理命令、注釈、文書要素外部[編集]

入力された文書 
<?xml version="1.0"?>
 
<?xml-stylesheet   href="doc.xsl"
   type="text/xsl"   ?>
 
<!DOCTYPE doc SYSTEM "doc.dtd">
 
<doc>Hello, world!<!-- 注釈 1 --></doc>
 
<?pi-without-data     ?>
 
<!-- 注釈 2 -->
 
<!-- 注釈 3 -->
正則形式（注釈なし） 
<?xml-stylesheet href="doc.xsl"
   type="text/xsl"   ?>
<doc>Hello, world!</doc>
<?pi-without-data?>
正則形式（注釈付き） 
<?xml-stylesheet href="doc.xsl"
   type="text/xsl"   ?>
<doc>Hello, world!<!-- 注釈 1 --></doc>
<?pi-without-data?>
<!-- 注釈 2 -->
<!-- 注釈 3 -->

実例:

  • XML宣言の脱落
  • DTDの脱落
  • 文書要素外部の空白文字の正規化（両方の正則形式の最初の文字は'<'であり、単独の改行は文書要素外部の処理命令と注釈を分離する）
  • 処理命令目標とそのデータの間にある空白文字の脱落
  • 処理命令データ内部の空白の保持
  • 非注釈化された正則形式からの、文書要素外部の注釈の改行文字を含む、注釈の削除（両方の正則形式の最後の文字がで'>'ある）

文書内容中の空白文字[編集]

入力された文書 
<doc>
   <clean>   </clean>
   <dirty>   A   B   </dirty>
   <mixed>
      A
      <clean>   </clean>
      B
      <dirty>   A   B   </dirty>
      C
   </mixed>
</doc>
正則形式 
<doc>
   <clean>   </clean>
   <dirty>   A   B   </dirty>
   <mixed>
      A
      <clean>   </clean>
      B
      <dirty>   A   B   </dirty>
      C
   </mixed>
</doc>

実例:

  • 連続した開始タグ間にある全ての空白文字の保持
  • 連続した終了タグ間にある全ての空白文字の保持
  • 終了タグと開始タグの対の間にある全ての空白文字の保持
  • 文字内容中の全ての空白の保持

註: この例では、入力された文書と正則形式がまったく同一である。両者は'>'文字で締めくくる。

開始タグと終了タグ[編集]

入力された文書 
<!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]>
<doc>
   <e1   />
   <e2   ></e2>
   <e3   name = "elem3"   id="elem3"   />
   <e4   name="elem4"   id="elem4"   ></e4>
   <e5 a:attr="out" b:attr="sorted" attr2="all" attr="I'm"
      xmlns:b="http://www.ietf.org"
      xmlns:a="http://www.w3.org"
      xmlns="http://example.org"/>
   <e6 xmlns="" xmlns:a="http://www.w3.org">
      <e7 xmlns="http://www.ietf.org">
         <e8 xmlns="" xmlns:a="http://www.w3.org">
            <e9 xmlns="" xmlns:a="http://www.ietf.org"/>
         </e8>
      </e7>
   </e6>
</doc>
正則形式 
<doc>
   <e1></e1>
   <e2></e2>
   <e3 id="elem3" name="elem3"></e3>
   <e4 id="elem4" name="elem4"></e4>
   <e5 xmlns="http://example.org" xmlns:a="http://www.w3.org" xmlns:b="http://www.ietf.org" attr="I'm" attr2="all" b:attr="sorted" a:attr="out"></e5>
   <e6 xmlns:a="http://www.w3.org">
      <e7 xmlns="http://www.ietf.org">
         <e8 xmlns="">
            <e9 xmlns:a="http://www.ietf.org" attr="default"></e9>
         </e8>
      </e7>
   </e6>
</doc>

実例:

  • 空要素の開始･終了タグ対への変換
  • 開始および終了タグ中の空白文字の正規化
  • 開始および終了タグ中の空白文字の正規化
  • 名前空間およびattribute軸の辞書式順序
  • 原本からの名前空間接頭辞の保持
  • 余計な名前空間宣言の排除
  • 既定属性の追加

註: 正則形式内のとある開始タグはとても長いが、この例の中のどの開始タグも完全に一行である

註: e5では、b:attrはa:attrの前に来る。なぜなら、優先キーが名前空間URIであり名前空間接頭辞でないからである。そして、attr2はb:attrの前に来る。なぜなら、既定名前空間が無制限の属性に当てはまらないからである（attr2の名前空間URIは空である）。

文字修正と文字参照[編集]

入力された文書 
<!DOCTYPE doc [
<!ATTLIST normId id ID #IMPLIED>
<!ATTLIST normNames attr NMTOKENS #IMPLIED>
]>
<doc>
   <text>一行目&#x0d;&#10;二行目</text>
   <value>&#x32;</value>
   <compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]></compute>
   <compute expr='value>"0" &amp;&amp; value&lt;"10" ?"valid":"error"'>valid</compute>
   <norm attr=' &apos;   &#x20;&#13;&#xa;&#9;   &apos; '/>
   <normNames attr='   A   &#x20;&#13;&#xa;&#9;   B   '/>
   <normId id=' &apos;   &#x20;&#13;&#xa;&#9;   &apos; '/>
</doc>
正則形式 
<doc>
   <text>一行目&#xD;
二行目</text>
   <value>2</value>
   <compute>value&gt;"0" &amp;&amp; value&lt;"10" ?"valid":"error"</compute>
   <compute expr="value>&quot;0&quot; &amp;&amp; value&lt;&quot;10&quot; ?&quot;valid&quot;:&quot;error&quot;">valid</compute>
   <norm attr=" '    &#xD;&#xA;&#x9;   ' "></norm>
   <normNames attr="A &#xD;&#xA;&#x9; B"></normNames>
   <normId id="' &#xD;&#xA;&#x9; '"></normId>
</doc>

実例:

  • 文字参照置き換え
  • 属性値区切り文字を引用符（ダブルクォート）に定める
  • 属性値の正規化
  • CATAセクションの置き換え
  • 属性値内の文字参照による特殊文字の符号化（&amp;、&lt;、&quot;、&#xD;、&#xA;、&#x9;）
  • テキスト内の文字参照による特殊文字の符号化（&amp;、&lt;、&gt;、&#xD;）

註: 最後の要素normIdは整形式ではあるが、ID型の属性のために妥当性制約に違反する。 妥当性を検証する処理装置に基づく正則なXMLの実装のテストでは、入力および正則形式からこの要素を含む行を削除する。一般的に、XML利用者はこのXMLの機能の使用をやめさせるべきである。

註: 空白文字は 以外を参照するので、XML 1.0勧告 [XML]の属性値正規化による影響を受けない。

註: 正則形式では、要素normでattrと名づけられた属性の値は空白文字、アポストロフィ（シングルクォート）で始まり、その時、最初の文字の前に四つ、間隔をあける。

註: compute要素の第二番目の属性exprは、改行を含まない。

実体参照[編集]

入力された文書 
<!DOCTYPE doc [
<!ATTLIST doc attrExtEnt ENTITY #IMPLIED>
<!ENTITY ent1 "Hello">
<!ENTITY ent2 SYSTEM "world.txt">
<!ENTITY entExt SYSTEM "earth.gif" NDATA gif>
<!NOTATION gif SYSTEM "viewgif.exe">
]>
<doc attrExtEnt="entExt">
   &ent1;, &ent2;!
</doc>
 
<!-- world.txtは"world"を含むとする（引用符は除いて） -->
正則形式（注釈なし） 
<doc attrExtEnt="entExt">
   Hello, world!
</doc>

実例:

  • 内部解析対象実体の置き換え
  • 外部解析対象実体の置き換え（要素と処理命令外の空白を含む）
  • 外部解析対象外実体の参照

UTF-8符号化[編集]

入力された文書 
<?xml version="1.0" encoding="ISO-8859-1"?>
<doc>&#169;</doc>
正則形式 
<doc>#xC2#xA9</doc>

実例:

  • 見本の符号化からUTF-8への符号変換作用

註: doc要素の内容は文字列#xC2#xA9ではなく[NOT]、むしろC2とA9という値をとった十六進数の二つのデータであり、それは著作権表記記号©のためのUCS符号位置のUTF-8符号化である。

文書部分集合[編集]

入力された文書 
<!DOCTYPE doc [
<!ATTLIST e2 xml:space (default|preserve) 'preserve'>
<!ATTLIST e3 id ID #IMPLIED>
]>
<doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org">
   <e1>
      <e2 xmlns="">
         <e3 id="E3"/>
      </e2>
   </e1>
</doc>
文書部分集合評価式 
<!-- 宣言 xmlns:ietf="http://www.ietf.org" を評価せよ -->
 
(//. | //@* | //namespace::*)
[
   self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2))
   or
   count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())
]
正則形式 
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3 xmlns="" id="E3" xml:space="preserve"></e3></e1>

実例:

  • 排除された親要素からの空の既定名前空間の伝播
  • 文書部分集合内のxml名前空間中の属性の伝播
  • 子孫内にある排除された名前空間宣言の持続

註: 文書部分集合評価式の中で、部分式(//. | //@* | //namespace::*)は入力された文書内の全ノードを選択し、大括弧中のそれぞれの述部式を支配下に置く。式がe1と暗黙の名前空間ノードのために真であり、そして、要素が（ancestor-or-selfが、E3によって特定された要素を伴う和集合の元で同じ範囲を保つように）コンテキストノードの(//. | //@* | //namespace::*)パス中にあるE3によって特定されたなら、評価式は真である。

註: 正則形式は改行文字を含まない。

文書部分集合とXML属性[編集]

入力された文書 
<!DOCTYPE doc [
<!ATTLIST e2 xml:space (default|preserve) 'preserve'>
<!ATTLIST e3 id ID #IMPLIED>
]>
<doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org" xml:base="something/else">
   <e1>
      <e2 xmlns="" xml:id="abc" xml:base="bar/">
         <e3 id="E3" xml:base="foo"/>
      </e2>
   </e1>
</doc>
文書部分集合評価式 
<!-- 宣言 xmlns:ietf="http://www.ietf.org" を評価せよ -->

(//. | //@* | //namespace::*)
[
   self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2))
   or
   count(id("E3")|ancestor-or-self::node()) = count(ancestor-or-self::node())
]
正則形式 
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org" xml:base="something/else"><e3 xmlns="" id="E3" xml:base="bar/foo" xml:space="preserve"></e3></e1>

正誤表E11-01を折り込み済みです。

実例:

  • xml:id属性の非継承
  • 単純継承可能XML属性の継承（xml:space）
  • xml:base属性の整理

決議[編集]

この節は、各決定のための論理的根拠と同様に、多くの重要な決定について検討する。また、この仕様書はこれから、XML情報セットというよりむしろXPathデータモデル規定でのXML正則化を定義する。この文書の中で記述される正則形式は、正則なXML2000年1月版草案 [C14N-20000119]で記述された正則形式を大きく尊重し、非常によく似ている。しかし、多くの相違が存在し、そして多くの小区分では変更について論じる。

XML宣言の禁止[編集]

バージョンナンバーと文字符号化法を含むXML宣言は、正則形式から削除される。正則形式はUTF-8で符号化されるので、符号化法は必要ない。 バージョンナンバーの欠如が疑いなくXML 1.0を指し示すので、バージョンは必要ない。

XMLの将来版では、バージョンナンバーを含んだXML宣言を含むことを要求されるかもしれない。しかし、いくばくかの修正点なしにXMLの将来版を適用できないかもしれない。新しい版のXMLの正則化が要求されるとき、恐らくはXPathデータモデルでのXML宣言の欠如がその時までに改善されるので、この仕様書はXML宣言を含んで更新されるかもしれない（例えば、情報セットデータモデルに基づく新しいXPathの再発行によって）。

文字モデル正規化の禁止[編集]

Unicode標準 [Unicode]では、若干の「合成済み文字（単純な例では"ç"）」の多目的な異なる表現を考慮する。 従って、多くのアプリケーションの目的上で等価な内容を持つ二つのXML文書は、異なる文字配列を含むかもしれない。 W3Cは正規化表現 [CharModel]を準備している。 正則なXML草案ではこの正規化形式を使用したが、多くのXML 1.0プロセッサではこの正規化が機能しない。その上、文字内容が別の方法で生じる処理失敗を回避するために作成されたとき、アプリケーションは、開始時に必ず文字モデル正規化を行って通常はこの問題を解決しなければならない（例えば、Cowanの例を見よ）。それ故、文字モデル正規化は、XML正則化の範囲外となった。しかし、UCSベース（現在、UCSベースの符号化はUTF-8、UTF-16、UTF-16BE、UTF-16LE、UCS-2、そしてUCS-4を含む）でないあらゆる符号化からUCS文字範囲へXML文書を変換する時に、XPathデータモデル入力に備えるXMLプロセッサは、正規化形式C [NFC, NFC-Corrigendum]を使うことを（データモデルによって）要求される。

文書要素外部の空白文字の取り扱い[編集]

正則なXML草案では、文書要素の終了タグの後にある#xAと同様に、文書要素外部の各処理命令後に#xAを設置する。この仕様書の方法では、最後の処理命令（または、注釈、でなければ文書要素の終了タグ）後の#xAの削除するという点を除いて、同じ機能を実行する。ルートノードまたは文書要素が出力から除外されても、この方法は　ルートの子である処理命令（および注釈）が、改行によってマークアップから分離されたことを保証する。

名前空間接頭辞の書き換え禁止[編集]

正則なXML草案では、論理的に等価な名前空間宣言を持つ二つの文書が、明確な名前空間接頭辞もまた持つような、名前空間の書き換え方法を定義した。最終目標は、論理的等価さをテスト中の文書で、特定の名前空間接頭辞上の付属物を削除することだった。 しかし、そこに今は、名前空間接頭辞がXML文書中の情報値を与える、多くの内容が存在する。例えば、属性値または要素内容中のXPath式は、名前空間接頭辞を参照することができる。 よって、名前空間接頭辞の書き換えは、その重要性によってそのような文書に被害を与える可能性がある（そして、その重要性が変更されていたなら、論理的に等価でなくなる恐れがある）。

より正式には、仮に、D1が属性値中またはD1内で使用した名前空間接頭辞を参照する要素内容中のXPathを含む文書であるとして、さらに、D1中の名前空間接頭辞が正則化法によってすべて書き換えられると仮定する。D2 = D1ならば、その時は、D2内の名前空間接頭辞を修正し、依然としてD2とD1が論理的に等価であるような名前空間接頭辞を参照するXPath式を修正する。名前空間は属性値や要素内容中の名前空間参照の発生を含まないので、D1の正則形式はD2の正則形式と等しくない。なぜなら、XPathが異なるからである。その結果、たとえ名前空間の書き換えが名前空間宣言を正規化しても、文書中の特定の名前空間接頭辞の付属物削除の目的が成し遂げらない。

さらにその上、名前空間の書き換えが、単に役に立たないというよりむしろ有害であるとわかることが可能である。D1が、D1内で使用された名前空間接頭辞を参照する要素内容または属性値の中のXPathを含む文書であるとして、その上でD1内の名前空間接頭辞が正則化法によってすべて書き換えられると仮定する。今、D2がD1の正則形式となるなら、明らかに、D1とD2の正則形式は等価であり（D2はD1の正則形式の正則形式なので）、にもかかわらず、D1とD2は論理的に等価でない。なぜなら、当該するXPathがD1では働き、D2では働かないからである。

これと似た議論は制限でのあらゆる事例に基づくXML正則化法に非難されるかもしれないが、ここで我々がかかる制限の導入をきっぱりと回避するための好機を得るのにかかわらず、問題がそのような事例で容易に修正されないかもしれないことに留意せよ。

論理的等価性の試験をしなければならないアプリケーションは、単なるバイトストリーム比較より、もっと高度の試験を実施する必要がある。しかしながら、他のXMLを参照した勧告、草案、将来の仕様などの規範と同様、アプリケーション規範に基づく論理的等価性試験のために、あらゆる事例で確実に必要になりそうである。

名前空間宣言と属性の順序[編集]

正則なXML草案では、名前空間宣言と属性宣言の間を行ったりきたりした。これは名前空間接頭辞書き換えの枠組みの一部であり、この仕様書では排除する。 この仕様書は、全属性ノードの前に全名前空間ノードを置くXPathデータモデルに従う。

余計な名前空間宣言[編集]

必要のない名前空間宣言は、正則形式内に作成されない。空の既定名前空間であろうと、空でない既定名前空間だろうと、名前空間接頭辞の結合だろうと、範囲中に等価な宣言を持つ正則形式内の直接の親要素が決定するならば、XML正則化法は宣言を削除する。親要素を持たないので、ルート文書要素は特別に取り扱われる。自動的に排除された空の既定名前空間宣言は除いて、ルート文書要素中の全名前空間宣言は留保される。

各要素の完全な名前空間コンテクストを単に表示する方法に関連して、実装は、処理時間と使用メモリにおける恒常的な要因以上の要因によって妨げられない。以下の利点が挙げられる。すなわち、

  • 実に名前空間を使わないかもしれない、もしくは最低限だけ名前空間に対応するアプリケーションの正則形式から、xmlns=""の超過を排除する
  • アプリケーションの内容モデルに従っているべきでないかもしれない要素から名前空間宣言を排除し、それにより文書型宣言を正則形式へ再添付する作業を簡素化する

文書部分集合の中では、その先祖要素の連鎖から排除された要素が、排除された祖先の中ですでに作成された名前空間宣言を伴う正則形式として表示され、その結果、文書の意味を保持するであろうことに留意せよ。

文書部分集合中の既定名前空間宣言の伝播[編集]

XPathデータモデルでは空の既定名前空間をノードが欠如したように表し、空値を持つ既定名前空間ノードの存在を示さない。従って、後述する例中の要素e3が修飾された名前空間にいない要因に対し、我々は<e1 xmlns="a:b"><e2 xmlns=""><e3/></e2></e1>と<e1 xmlns="a:b"><e2><e3 xmlns=""/></e2></e1>の違いを指摘できない。我々にわかることは、e3が入力上で修飾された名前空間にいないことが全てであるので、e2が排除される場合は、e3がe1の既定名前空間修飾を受けないように、出力上でこの情報を保持する。

名前空間URIによる属性の並び替え[編集]

文書中の名前空間接頭辞の保持要求が与えられると、名前空間URIよりむしろ接頭辞を優先キーとして属性を並び替えるほうが、実装が簡単で有望である。しかし、名前空間URIが優先キーとして選ばれた。なぜなら、接頭辞と局所名によってでなく、URIと局所名によって名前空間を見分けるというXML名前空間 1.0仕様書の意味に即しているからである。並び替えの効果は、同一の名前空間にある全属性を分類するためにある。

参考文献[編集]

C14N10
正則なXML 1.0 W3C勧告
Canonical XML Version 1.0, W3C Recommendation. ed. J. Boyer. 15 March 2001.http://www.w3.org/TR/xml-c14n.
C14N-20000119
正則なXML 1.0 W3C作業草案
Canonical XML Version 1.0, W3C Working Draft. T. Bray, J. Clark, J. Tauber, and J. Cowan. January 19, 2000. http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html.
C14N-Issues
正則なXML 1.0の既知の問題
Known Issues with Canonical XML 1.0, W3C Working Group Note. J. Kahan, K. Lanz. December 2006. http://www.w3.org/TR/C14N-issues/.
CharModel
ワールドワイドウェブのための文字モデル
Character Model for the World Wide Web, W3C Working Draft. eds. Martin J. Durst, Francois Yergeau, Misha Wolf, Asmus Freytag and Tex Texin. http://www.w3.org/TR/charmod/.
Cowan
文字モデル正規化の有害な効果の例
Example of Harmful Effect of Character Model Normalization, Letter in XML Signature Working Group Mail Archive. John Cowan, July 7, 2000. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0038.html.
DSig-Usage
文字モデル正規化の有害な効果の例
Using XML Digital Signatures in the 2006 XML Environment, W3C Working Group Note. Thomas Roessler. December 2006. http://www.w3.org/TR/DSig-usage/.
Infoset
XML情報セット
XML Information Set, W3C Working Draft. eds. John Cowan and Richard Tobin. http://www.w3.org/TR/xml-infoset/.
ISO-8859-1
ISO-8859-1 ラテン 1 文字セット
ISO-8859-1 Latin 1 Character Set, http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html or http://www.iso.org/iso/iso_catalogue.htm.
Keywords
RFC利用において必要なレベルを示すキーワード
Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119. S. Bradner. March 1997. http://www.ietf.org/rfc/rfc2119.txt.
Namespaces
XML名前空間
Namespaces in XML 1.0 (Second Edition), W3C Recommendation. eds. Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin. http://www.w3.org/TR/REC-xml-names/.
NFC
Unicode正規化方式C 技術文書番号15
TR15, Unicode Normalization Forms. M. Davis, M. Durst. Revision 18: November 1999. http://www.unicode.org/unicode/reports/tr15/tr15-18.html.
NFC-Corrigendum
正規化正誤表
Normalization Corrigendum. The Unicode Consortium. http://www.unicode.org/unicode/uni2errata/Normalization_Corrigendum.html.
Unicode
The Unicode Standard, version 3.0. The Unicode Consortium. ISBN 0-201-61633-5. http://www.unicode.org/unicode/standard/versions/Unicode3.0.html.
UTF-16
UTF-16, an encoding of ISO 10646, IETF RFC 2781. P. Hoffman , F. Yergeau. February 2000. http://www.ietf.org/rfc/rfc2781.txt.
UTF-8
UTF-8, a transformation format of ISO 10646, IETF RFC 2279. F. Yergeau. January 1998. http://www.ietf.org/rfc/rfc2279.txt.
URI
統一資源識別子
Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC 3986. T. Berners-Lee, R. Fielding, L. Masinter. January 2005 http://www.ietf.org/rfc/rfc3986.txt.
XBase
XML Base ed. Jonathan Marsh. 07 June 2000. http://www.w3.org/TR/xmlbase/.
XML
拡張可能なマーク付け言語 1.0
Extensible Markup Language (XML) 1.0 (Fourth Edition), W3C Recommendation. eds. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Francois Yergeau and Eve Maler. 16 August 2006. http://www.w3.org/TR/REC-xml/.
XML DSig
XML署名 文法と処理方法
XML-Signature Syntax and Processing, IETF Draft/W3C Candidate Recommendation. D. Eastlake, J. Reagle, D. Solo, M. Bartel, J. Boyer, B. Fox, and E. Simon. 31 October 2000. http://www.w3.org/TR/xmldsig-core/.
XML-ID
XML ID
xml:id Version 1.0, W3C Recommendation. eds. Norman Walsh, Daniel Veillard and Jonathan Marsh. 9 September 2005. http://www.w3.org/TR/xml-id/.
XML Plenary Decision
名前空間宣言中の相対URI参照におけるW3C XML無条件決議
W3C XML Plenary Decision on relative URI References In namespace declarations, W3C Document. 11 September 2000. http://lists.w3.org/Archives/Public/xml-uri/2000Sep/0083.html.
XPath
XMLパス言語 1.0
XML Path Language (XPath) Version 1.0, W3C Recommendation. eds. James Clark and Steven DeRose. 16 November 1999. http://www.w3.org/TR/1999/REC-xpath-19991116.

付録A[編集]

次の参考表では、第2.4節に記された変更済みドット部分削除アルゴリズムの結果例を少しまとめている。

入力 出力
no/.././/pseudo-netpath/seg/file.ext pseudo-netpath/seg/file.ext
no/..//.///pseudo-netpath/seg/file.ext pseudo-netpath/seg/file.ext
yes/no//..//.///pseudo-netpath/seg/file.ext yes/pseudo-netpath/seg/file.ext
no/../yes yes
no/../yes/ yes/
no/../yes/no/.. yes/
../../no/../.. ../../../
no/../.. ../
no/..  
no/../  
/a/b/c/./../../g /a/g
mid/content=5/../6 mid/6
../../.. ../../../
no/../../ ../
..yes/..no/..no/..no/../../../..yes ..yes/..yes
..yes/..no/..no/..no/../../../..yes/ ..yes/..yes/
../.. ../../
../../../ ../../../
.  
./  
./.  
//no/.. /
../../no/.. ../../
../../no/../ ../../
yes/no/../ yes/
yes/no/no/../.. yes/
yes/no/no/no/../../.. yes/
yes/no/../yes/no/no/../.. yes/yes/
yes/no/no/no/../../../yes yes/yes
yes/no/no/no/../../../yes/ yes/yes/
/no/../ /
/yes/no/../ /yes/
/yes/no/no/../.. /yes/
/yes/no/no/no/../../.. /yes/
../../..no/.. ../../
../../..no/../ ../../
..yes/..no/../ ..yes/
..yes/..no/..no/../.. ..yes/
..yes/...no/..no/..no/../../.. ..yes/
..yes/..no/../..yes/..no/..no/../.. ..yes/..yes/
/..no/../ /
/..yes/..no/../ /..yes/
/..yes/..no/..no/../.. /..yes/
/..yes/..no/..no/..no/../../.. /..yes/
/ /
/. /
/./ /
/./. /
/././ /
/.. /
/../.. /
/../../.. /
/../../.. /
//.. /
//..//.. /
//..//..//.. /
/./.. /
/./.././.. /
/./.././.././.. /
.  
./  
./.  
.. ../
../ ../
「https://wiki.s13e.net/index.php?title=正則なXML_バージョン_1.1&oldid=1610」から取得