RFC3076 日本語訳
3076 Canonical XML Version 1.0. J. Boyer. March 2001. (Format: TXT=63955 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Boyer Request for Comments: 3076 PureEdge Solutions Inc. Category: Informational March 2001
コメントを求めるワーキンググループJ.ボワイエ要求をネットワークでつないでください: 3076年のPureEdgeソリューション株式会社カテゴリ: 情報の2001年3月
Canonical XML Version 1.0
正準なXMLバージョン1.0
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
Any XML (Extensible Markup Language) document is part of a set of XML documents that are logically equivalent within an application context, but which vary in physical representation based on syntactic changes permitted by XML 1.0 and Namespaces in XML. This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. Except for limitations regarding a few unusual cases, if two documents have the same canonical form, then the two documents are logically equivalent within the given application context. Note that two documents may have differing canonical forms yet still be equivalent in a given context based on application-specific equivalence rules for which no generalized XML specification could account.
どんなXML(拡張マークアップ言語)ドキュメントもアプリケーション文脈の中で論理的に同等ですが、XMLでXML1.0とNamespacesによって可能にされた構文の変化に基づく具現において異なる1セットのXMLドキュメントの一部です。 具現を生成する許されている変化の原因になるXMLドキュメントの標準形のためにこの仕様はメソッドを説明します。 いくつかの珍しいケースでの制限を除いて、2通のドキュメントに同じ標準形があるなら、2通のドキュメントが与えられたアプリケーション文脈の中で論理的に同等です。 2通のドキュメントが、異なった標準形が一般化されたXML仕様が全く説明されることができなかったアプリケーション特有の等価性規則に基づく与えられた文脈でまだまだ同等であることを持っているかもしれないことに注意してください。
Boyer Informational [Page 1] RFC 3076 Canonical XML March 2001
2001年の[1ページ]RFC3076の正準なXML行進の情報のボワイエ
Table of Contents
目次
1. Introduction............................................... 2
1.1 Terminology............................................... 3
1.2 Applications.............................................. 4
1.3 Limitations............................................... 4
2. XML Canonicalization....................................... 6
2.1 Data Model................................................ 6
2.2 Document Order............................................ 10
2.3 Processing Model.......................................... 10
2.4 Document Subsets.......................................... 13
3. Examples of XML Canonicalization........................... 14
3.1 PIs, Comments, and Outside of Document Element............ 14
3.2 Whitespace in Document Content............................ 15
3.3 Start and End Tags........................................ 16
3.4 Character Modifications and Character References.......... 17
3.5 Entity References......................................... 19
3.6 UTF-8 Encoding............................................ 19
3.7 Document Subsets.......................................... 20
4. Resolutions................................................ 21
4.1 No XML Declaration........................................ 21
4.2 No Character Model Normalization.......................... 21
4.3 Handling of Whitespace Outside Document Element........... 22
4.4 No Namespace Prefix Rewriting............................. 22
4.5 Order of Namespace Declarations and Attributes............ 23
4.6 Superfluous Namespace Declarations........................ 23
4.7 Propagation of Default Namespace Declaration in Document
Subsets................................................... 24
4.8 Sorting Attributes by Namespace URI....................... 24
Security Considerations....................................... 24
References.................................................... 25
Author's Address.............................................. 26
Acknowledgements.............................................. 27
Full Copyright Statement...................................... 28
1. 序論… 2 1.1用語… 3 1.2のアプリケーション… 4 1.3の制限… 4 2. XML Canonicalization… 6 2.1のデータがモデル化されます… 6 2.2 オーダーを記録してください… 10 2.3処理モデル… 10 2.4 部分集合を記録してください… 13 3. XML Canonicalizationに関する例… 14 ドキュメント要素の3.1PIs、コメント、および外部… 14 ドキュメント内容の3.2空白… 15 3.3 始めてください、そして、タグを終わらせてください… 16 3.4 キャラクター変更とキャラクター参照… 17 3.5 実体参照… 19 3.6 UTF-8コード化… 19 3.7 部分集合を記録してください… 20 4. 解決… 21 4.1 XML宣言がありません… 21 4.2 キャラクターモデル正常化がありません… 21 4.3 空白外部ドキュメント要素の取り扱い… 22 4.4 名前空間接頭語の書き直さないこと… 22 4.5 名前空間宣言と属性の注文… 23 4.6 余計な名前空間宣言… 23 4.7 ドキュメント部分集合における、デフォルト名前空間宣言の伝播… 24 4.8 名前空間URIは属性を分類します… 24 セキュリティ問題… 24の参照箇所… 25作者のアドレス… 26の承認… 27 完全な著作権宣言文… 28
1. Introduction
1. 序論
The XML 1.0 Recommendation [XML] specifies the syntax of a class of resources called XML documents. The Namespaces in XML Recommendation [Names] specifies additional syntax and semantics for XML documents. It is possible for XML documents which are equivalent for the purposes of many applications to differ in physical representation. For example, they may differ in their entity structure, attribute ordering, and character encoding. It is the goal of this specification to establish a method for determining whether two documents are identical, or whether an application has not changed a document, except for transformations permitted by XML 1.0 and Namespaces.
XML1.0Recommendation[XML]はXMLドキュメントと呼ばれるリソースのクラスの構文を指定します。 XML Recommendation[名前]のNamespacesは追加構文と意味論をXMLドキュメントに指定します。 同等なXMLドキュメントに、多くのアプリケーションの目的が具現において異なるのは、可能です。 例えば、彼らはそれらの実体構造、属性注文、および文字符号化において異なるかもしれません。 それは2通のドキュメントが同じであるかどうか、またはアプリケーションがドキュメントを変えていないかどうか決定するためのメソッドを確立するこの仕様の目標です、XML1.0とNamespacesによって可能にされた変換を除いて。
Boyer Informational [Page 2] RFC 3076 Canonical XML March 2001
2001年の[2ページ]RFC3076の正準なXML行進の情報のボワイエ
1.1 Terminology
1.1 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [Keywords].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
See [Names] for the definition of QName.
QNameの定義に関して[名前]を見てください。
A document subset is a portion of an XML document indicated by a node-set that may not include all of the nodes in the document.
ドキュメント部分集合はドキュメントにノードのすべてを含まないかもしれないノードセットによって示されたXMLドキュメントの一部です。
The canonical form of an XML document is physical representation of the document produced by the method described in this specification. The changes are summarized in the following list:
XMLドキュメントの標準形はこの仕様で説明されたメソッドで製作されたドキュメントの具現です。 変化は以下のリストにまとめられます:
* The document is encoded in UTF-8
* Line breaks normalized to #xA on input, before parsing
* Attribute values are normalized, as if by a validating
processor
* Character and parsed entity references are replaced
* CDATA sections are replaced with their character content
* The XML declaration and document type declaration (DTD) are
removed
* Empty elements are converted to start-end tag pairs
* Whitespace outside of the document element and within start and
end tags is normalized
* All whitespace in character content is retained (excluding
characters removed during line feed normalization)
* Attribute value delimiters are set to quotation marks (double
quotes)
* Special characters in attribute values and character content
are replaced by character references
* Superfluous namespace declarations are removed from each
element
* Default attributes are added to each element
* Lexicographic order is imposed on the namespace declarations
and attributes of each element
* ドキュメントは入力のときに#xAに正常にされたUTF-8*ラインブレイクでコード化されます、構文解析*属性値が正常にされる前に; *まるで参照が有効にするプロセッサ*キャラクターと解析対象実体による取り替えられた*CDATA部がXML宣言とドキュメントがタイプするそれらのキャラクタ内容*に取り替えて、(DTD)が取り外された*空の要素がスタート終了タグに変換されるということであるという宣言がドキュメント要素の外と*空白を対にして、始めと終了タグの中で正常にされるということであるということであるかのように、キャラクタ内容のすべての空白が保有されます; (改行正常化の間に外されたキャラクタを除いた) *属性値デリミタは属性値における引用符(二重引用符)*特殊文字へのセットとキャラクタ内容が余計な名前空間宣言がそれぞれ取り除かれる文字参照*に取り替えて、要素*省略時の属性がそれぞれのそれぞれの名前空間宣言と属性に課された要素*辞書式順序要素に追加されるということであるということです。
The term canonical XML refers to XML that is in canonical form. The XML canonicalization method is the algorithm defined by this specification that generates the canonical form of a given XML document or document subset. The term XML canonicalization refers to the process of applying the XML canonicalization method to an XML document or document subset.
正準であるという用語XMLは標準形にあるXMLについて言及します。 XML canonicalizationメソッドは与えられたXMLドキュメントかドキュメント部分集合の標準形を生成するこの仕様で定義されたアルゴリズムです。 XML canonicalizationという用語はXMLドキュメントかドキュメント部分集合にXML canonicalizationメソッドを適用するプロセスについて言及します。
The XPath 1.0 Recommendation [XPath] defines the term node-set and specifies a data model for representing an input XML document as a set of nodes of various types (element, attribute, namespace, text,
XPath1.0Recommendation[XPath]が様々なタイプのノードのセットとして入力XMLドキュメントを表すのに用語ノードセットを定義して、データモデルを指定する、(要素、属性、名前空間、テキスト
Boyer Informational [Page 3] RFC 3076 Canonical XML March 2001
2001年の[3ページ]RFC3076の正準なXML行進の情報のボワイエ
comment, processing instruction, and root). The nodes are included in or excluded from a node-set based on the evaluation of an expression. Within this specification, a node-set is used to directly indicate whether or not each node should be rendered in the canonical form (in this sense, it is used as a formal mathematical set). A node that is excluded from the set is not rendered in the canonical form being generated, even if its parent node is included in the node-set. However, an omitted node may still impact the rendering of its descendants (e.g., by augmenting the namespace context of the descendants).
コメント、処理命令、および根) ノードは式の評価を、含まれているか、またはベースのノードセットから除かれます。 この仕様の中では、ノードセットは、各ノードが標準形に表されるべきであるかどうかを(この意味で、それは正式な数学のセットとして使用されます)直接示すのに使用されます。 セットから除かれるノードは生成される標準形に表されません、親ノードがノードセットに含まれても。 しかしながら、省略されたノードはまだ子孫(例えば、子孫の名前空間文脈を増大させるのによる)のレンダリングに影響を与えているかもしれません。
1.2 Applications
1.2 アプリケーション
Since the XML 1.0 Recommendation [XML] and the Namespaces in XML Recommendation [Names] define multiple syntactic methods for expressing the same information, XML applications tend to take liberties with changes that have no impact on the information content of the document. XML canonicalization is designed to be useful to applications that require the ability to test whether the information content of a document or document subset has been changed. This is done by comparing the canonical form of the original document before application processing with the canonical form of the document result of the application processing.
XML1.0Recommendation[XML]とXML RecommendationのNamespaces[名前]が同じ情報を言い表すための複数の構文のメソッドを定義するので、XMLアプリケーションは、ドキュメントに関する情報量に影響力を全く持っていない変化に無礼なことをする傾向があります。 XML canonicalizationは、ドキュメントかドキュメント部分集合に関する情報量を変えたか否かに関係なく、テストする能力を必要とするアプリケーションの役に立つように設計されています。 手続きの経緯の前に手続きの経緯のドキュメント結果の標準形に正本の標準形をたとえることによって、これをします。
For example, a digital signature over the canonical form of an XML document or document subset would allow the signature digest calculations to be oblivious to changes in the original document's physical representation, provided that the changes are defined to be logically equivalent by the XML 1.0 or Namespaces in XML. During signature generation, the digest is computed over the canonical form of the document. The document is then transferred to the relying party, which validates the signature by reading the document and computing a digest of the canonical form of the received document. The equivalence of the digests computed by the signing and relying parties (and hence the equivalence of the canonical forms over which they were computed) ensures that the information content of the document has not been altered since it was signed.
例えば、XMLドキュメントかドキュメント部分集合の標準形でのデジタル署名は、署名ダイジェスト計算に正本の具現における変化に気づかないのを許容するでしょう、変化がXMLのXML1.0かNamespacesで論理的に相当しているように定義されれば。 署名世代の間、ダイジェストはドキュメントの標準形で計算されます。 そして、信用パーティーにドキュメントを移します。(そのパーティーは、ドキュメントを読んで、受け取られていているドキュメントの標準形のダイジェストを計算することによって、署名を有効にします)。 署名と信用パーティー(そして、したがって、それらが計算された標準形の等価性)によって計算されたダイジェストの等価性は、それが署名されて以来ドキュメントに関する情報量が変更されていないのを確実にします。
1.3 Limitations
1.3 制限
Two XML documents may have differing information content that is nonetheless logically equivalent within a given application context. Although two XML documents are equivalent (aside from limitations given in this section) if their canonical forms are identical, it is not a goal of this work to establish a method such that two XML documents are equivalent if and only if their canonical forms are identical. Such a method is unachievable, in part due to application-specific rules such as those governing unimportant
2通のXMLドキュメントには、与えられたアプリケーション文脈の中でそれにもかかわらず、論理的に同等な異なった情報量があるかもしれません。 そして、2通のXMLドキュメントがそれらの標準形が同じであるなら2通のXMLドキュメントが同等ですが(このセクションで与えられた制限は別として)、それがメソッドを確立するこの仕事の目標でないので同等である、それらの標準形が同じである場合にだけ。 そのようなメソッドは一部治める重要でないそれらなどのアプリケーション特有の規則のために「非-達成可能」です。
Boyer Informational [Page 4] RFC 3076 Canonical XML March 2001
2001年の[4ページ]RFC3076の正準なXML行進の情報のボワイエ
whitespace and equivalent data (e.g., <color>black</color> versus <color>rgb(0,0,0)</color>). There are also equivalencies established by other W3C Recommendations and Working Drafts. Accounting for these additional equivalence rules is beyond the scope of this work. They can be applied by the application or become the subject of future specifications.
空白と同等なデータ(例えば、<カラー>の黒い</カラー>対<カラー>rgb(0、0、0)</カラー>)。 また、他のW3C RecommendationsとWorking Draftsによって設立されたequivalenciesがあります。 これらの追加等価性規則のための会計はこの仕事の範囲を超えています。 それらは、アプリケーションで適用されるか、または将来の仕様の対象になることができます。
The canonical form of an XML document may not be completely operational within the application context, though the circumstances under which this occurs are unusual. This problem may be of concern in certain applications since the canonical form of a document and the canonical form of the canonical form of the document are equivalent. For example, in a digital signature application, the canonical form can be substituted for the original document without changing the digest calculation. However, the security risk only occurs in the unusual circumstances described below, which can all be resolved or at least detected prior to digital signature generation.
XMLドキュメントの標準形はアプリケーション文脈の中で完全に操作上であるかもしれないというわけではありません、これが起こる事情が珍しいのですが。 ドキュメントの標準形とドキュメントの標準形の標準形が同等であるので、この問題はあるアプリケーションで重要であるかもしれません。 例えば、デジタル署名アプリケーションでは、ダイジェスト計算を変えないで、正本に標準形を代入できます。 しかしながら、セキュリティリスクは以下で説明された珍しい事情に起こるだけです。(すべて決議しているか、またはデジタル署名世代の前に事情を少なくとも検出できます)。
The difficulties arise due to the loss of the following information not available in the data model:
困難はデータモデルで利用可能でない以下の情報の損失のため起こります:
1. base URI, especially in content derived from the replacement
text of external general parsed entity references
2. notations and external unparsed entity references
3. attribute types in the document type declaration
1. 特に外部の一般的な解析対象実体参照2記法と外部の解析対象外実体参照3属性タイプの交換テキストからドキュメント型の宣言で得られた内容のベースURI
In the first case, note that a document containing a relative URI [URI] is only operational when accessed from a specific URI that provides the proper base URI. In addition, if the document contains external general parsed entity references to content containing relative URIs, then the relative URIs will not be operational in the canonical form, which replaces the entity reference with internal content (thereby implicitly changing the default base URI of that content). Both of these problems can typically be solved by adding support for the xml:base attribute [XBase] to the application, then adding appropriate xml:base attributes to document element and all top-level elements in external entities. In addition, applications often have an opportunity to resolve relative URIs prior to the need for a canonical form. For example, in a digital signature application, a document is often retrieved and processed prior to signature generation. The processing SHOULD create a new document in which relative URIs have been converted to absolute URIs, thereby mitigating any security risk for the new document.
前者の場合、適切なベースURIを提供する特定のURIからアクセスされると相対的なURI[URI]を含むドキュメントが操作上であるだけであることに注意してください。 さらに、ドキュメントが相対的なURIを含む内容の外部の一般的な解析対象実体参照を含んでいると、相対的なURIは標準形でならないでしょう(その結果、それとなくその内容のデフォルトベースURIを変えます)。(それは、操作上であり、実体参照を内部の内容に取り替えます)。 xmlのサポートを加えることによって、これらの問題の両方を通常解決できます: 属性[XBase]をアプリケーションに基礎づけてください、適切なxmlがその時加えて: 外部実体で属性をドキュメント要素とすべてのトップレベル要素まで基礎づけてください。 さらに、アプリケーションには、標準形の必要性の前に相対的なURIを決議する機会がしばしばあります。 例えば、デジタル署名アプリケーションでは、文書は、しばしば検索されて、署名世代の前に処理されます。 処理SHOULDは相対的なURIが絶対URIに変換された新しいドキュメントを作成します、その結果、新しいドキュメントのためにどんなセキュリティリスクも緩和します。
In the second case, the loss of external unparsed entity references and the notations that bind them to applications means that canonical forms cannot properly distinguish among XML documents that incorporate unparsed data via this mechanism. This is an unusual
2番目の場合では、標準形が盛込まれるXMLドキュメントの中で適切に区別できないアプリケーション手段にそれらを縛る外部の解析対象外実体参照と記法の損失はこのメカニズムでデータを非分析しました。 これがそうである、まれ
Boyer Informational [Page 5] RFC 3076 Canonical XML March 2001
2001年の[5ページ]RFC3076の正準なXML行進の情報のボワイエ
case precisely because most XML processors currently discard the document type declaration, which discards the notation, the entity's binding to a URI, and the attribute type that binds the attribute value to an entity name. For documents that must be subjected to more than one XML processor, the XML design typically indicates a reference to unparsed data using a URI in the attribute value.
まさにほとんどのXMLプロセッサが現在ドキュメント型の宣言(記法、URIとの実体の結合、および実体名に属性値を縛る属性タイプを捨てる)を捨てるので、ケースに入れます。 1台以上のXMLプロセッサにかけなければならないドキュメントに関しては、XMLデザインは、属性値にURIを使用することで非分析されたデータの参照を通常示します。
In the third case, the loss of attribute types can affect the canonical form in different ways depending on the type. Attributes of type ID cease to be ID attributes. Hence, any XPath expressions that refer to the canonical form using the id() function cease to operate. The attribute types ENTITY and ENTITIES are not part of this case; they are covered in the second case above. Attributes of enumerated type and of type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS, and NOTATION fail to be appropriately constrained during future attempts to change the attribute value if the canonical form replaces the original document during application processing. Applications can avoid the difficulties of this case by ensuring that an appropriate document type declaration is prepended prior to using the canonical form in further XML processing. This is likely to be an easy task since attribute lists are usually acquired from a standard external DTD subset, and any entity and notation declarations not also in the external DTD subset are typically constructed from application configuration information and added to the internal DTD subset.
3番目の場合では、属性タイプの損失はタイプに頼る異なった方法で標準形に影響できます。 タイプIDの属性は、ID属性であることをやめます。 したがって、イド()機能を使用することで標準形について言及するどんなXPath式も、作動するのをやめます。 属性タイプのENTITYとENTITIESは本件の一部ではありません。 それらは上の2番目の場合でカバーされています。 標準形が手続きの経緯の間、正本を置き換えるなら、属性値を変える将来の試みの間、列挙型とタイプIDの属性、IDREF、IDREFS、NMTOKEN、NMTOKENS、およびNOTATIONによって適切に抑制されません。 さらなるXML処理に標準形を使用する前に適切なドキュメント型の宣言がprependedされるのを確実にすることによって、アプリケーションは本件の困難を避けることができます。 これが標準の外部のDTD部分集合から属性リストを通常取得するので楽な仕事である傾向があり、外部のDTD部分集合におけるどんな実体と記法宣言も、アプリケーション設定情報から通常構成されて、内部のDTD部分集合に追加されます。
While these limitations are not severe, it would be possible to resolve them in a future version of XML canonicalization if, for example, a new version of XPath were created based on the XML Information Set [Infoset] currently under development at the W3C.
これらの制限が厳しくない間、例えば、XPathの新しいバージョンが現在W3Cの開発中のXML情報Set[Infoset]に基づいて作成されるなら、XML canonicalizationの将来のバージョンでそれらを決議するのは可能でしょうに。
2. XML Canonicalization
2. XML Canonicalization
2.1 Data Model
2.1 データモデル
The data model defined in the XPath 1.0 Recommendation [XPath] is used to represent the input XML document or document subset. Implementations SHOULD but need not be based on an XPath implementation. XML canonicalization is defined in terms of the XPath definition of a node-set, and implementations MUST produce equivalent results.
XPath1.0Recommendation[XPath]で定義されたデータモデルは、入力XMLドキュメントかドキュメント部分集合を表すのに使用されます。 実装SHOULDにもかかわらず、必要性はXPath実装に基づいたそうではありません。 XML canonicalizationは1つのノードセットのXPath定義で定義されます、そして、実装は同等な結果を生まなければなりません。
The first parameter of input to the XML canonicalization method is either an XPath node-set or an octet stream containing a well-formed XML document. Implementations MUST support the octet stream input and SHOULD also support the document subset feature via node-set input. For the purpose of describing canonicalization in terms of an XPath node-set, this section describes how an octet stream is converted to an XPath node-set.
XML canonicalizationメソッドへの入力の最初のパラメタは、XPathノードセットか整形式のXMLドキュメントを含む八重奏ストリームのどちらかです。 実装は八重奏ストリーム入力をサポートしなければなりません、そして、また、SHOULDはノードに設定にされるを通したドキュメント部分集合特徴入力をサポートします。 XPathノードセットに関してcanonicalizationについて説明する目的のために、このセクションは八重奏ストリームがどう変えられるかをXPathノードセットに説明します。
Boyer Informational [Page 6] RFC 3076 Canonical XML March 2001
2001年の[6ページ]RFC3076の正準なXML行進の情報のボワイエ
The second parameter of input to the XML canonicalization method is a boolean flag indicating whether or not comments should be included in the canonical form output by the XML canonicalization method. If a canonical form contains comments corresponding to the comment nodes in the input node-set, the result is called canonical XML with comments. Note that the XPath data model does not create comment nodes for comments appearing within the document type declaration (DTD). Implementations are REQUIRED to be capable of producing canonical XML excluding all comments that may have appeared in the input document or document subset. Support for canonical XML with comments is RECOMMENDED.
XML canonicalizationメソッドへの入力の2番目のパラメタはコメントが標準形出力にXML canonicalizationメソッドで含まれるべきであるかどうかを示す論理演算子旗です。 標準形が入力ノードセットでコメントノードに対応するコメントを含んでいるなら、結果はコメントで正準なXMLと呼ばれます。 XPathデータモデルがドキュメント型の宣言(DTD)の中に現れるコメントのためのコメントノードを作成しないことに注意してください。 実装は入力ドキュメントかドキュメント部分集合に載ったかもしれないすべてのコメントを除いた正準なXMLを生産できるREQUIREDです。 コメントによる正準なXMLのサポートはRECOMMENDEDです。
If an XML document must be converted to a node-set, XPath REQUIRES that an XML processor be used to create the nodes of its data model to fully represent the document. The XML processor performs the following tasks in order:
データのノードを作成するのに使用されて、XMLドキュメントを変換しなければならないならノードセット、XMLプロセッサがあるXPath REQUIRESにモデル化して、ドキュメントを完全に表してください。 XMLプロセッサは整然とした状態で以下のタスクを実行します:
1. normalize line feeds
2. normalize attribute values
3. replace CDATA sections with their character content
4. resolve character and parsed entity references
1. 改行2を正常にしてください。属性値3を正常にしてください。CDATA部を彼らのキャラクタ内容4決心キャラクタと解析対象実体参照に取り替えてください。
The input octet stream MUST contain a well-formed XML document, but the input need not be validated. However, the attribute value normalization and entity reference resolution MUST be performed in accordance with the behaviors of a validating XML processor. As well, nodes for default attributes (declared in the ATTLIST with an AttValue but not specified) are created in each element. Thus, the declarations in the document type declaration are used to help create the canonical form, even though the document type declaration is not retained in the canonical form.
入力八重奏ストリームは整形式のXMLドキュメントを含まなければなりませんが、入力は有効にされる必要はありません。 しかしながら、有効にしているXMLプロセッサの振舞いに従って、属性値正常化と実体参照解決を実行しなければなりません。 また、省略時の属性(AttValueと共にATTLISTで宣言されますが、指定されない)のためのノードは各要素で作成されます。 したがって、ドキュメント型の宣言における宣言は標準形を作成するのを助けるのに使用されます、ドキュメント型の宣言が標準形で保有されませんが。
The XPath data model represents data using UCS characters. Implementations MUST use XML processors that support UTF-8 and UTF-16 and translate to the UCS character domain. For UTF-16, the leading byte order mark is treated as an artifact of encoding and stripped from the UCS character data (subsequent zero width non-breaking spaces appearing within the UTF-16 data are not removed) [UTF-16, Section 3.2]. Support for ISO-8859-1 encoding is RECOMMENDED, and all other character encodings are OPTIONAL.
XPathデータモデルは、UCSキャラクタを使用することでデータを表します。 実装は、UTF-8とUTF-16をサポートするXMLプロセッサを使用して、UCSキャラクタドメインに翻訳されなければなりません。 UTF-16に関しては、主なバイト・オーダー・マークをコード化の人工物として扱って、UCSキャラクタデータから剥取ります(UTF-16データの中に現れる幅の非の壊さないことのその後の空間は取り除かれません)[UTF-16、セクション3.2]。 ISO-8859-1コード化のサポートはRECOMMENDEDです、そして、他のすべての文字符号化がOPTIONALです。
All whitespace within the root document element MUST be preserved (except for any #xD characters deleted by line delimiter normalization). This includes all whitespace in external entities. Whitespace outside of the root document element MUST be discarded.
根のドキュメント要素の中のすべての空白を保持しなければなりません(系列デリミタ正常化で削除されたどんな#xDキャラクタを除いても)。 これは外部実体にすべての空白を含んでいます。 捨てられて、根のドキュメント要素の外部がそうしなければならない空白。
Boyer Informational [Page 7] RFC 3076 Canonical XML March 2001
2001年の[7ページ]RFC3076の正準なXML行進の情報のボワイエ
In the XPath data model, there exist the following node types: root, element, comment, processing instruction, text, attribute and namespace. There exists a single root node whose children are processing instruction nodes and comment nodes to represent information outside of the document element (and outside of the document type declaration). The root node also has a single element node representing the top-level document element. Each element node can have child nodes of type element, text, processing instruction, and comment. The attributes and namespaces associated with an element are not considered to be child nodes of the element, but they are associated with the element by inclusion in the element's attribute and namespace axes. Note that attribute and namespace axes may not directly correspond to the text appearing in the element's start tag in the original document.
XPathデータモデルでは、以下のノード種別は存在します: 指示、テキスト、属性、および名前空間を処理して、根、要素はコメントします。 子供が指示ノードを処理しているただ一つの根のノードとコメントノードは、ドキュメント要素の外(ドキュメント型の宣言の外)に情報を表すために存在します。 また、根のノードで、ただ一つの要素ノードはトップレベルドキュメント要素を表します。 それぞれの要素ノードはタイプ・エレメント、テキスト、処理命令、およびコメントの子供ノードを持つことができます。 要素に関連している属性と名前空間は要素の子供ノードであると考えられませんが、それらは要素の属性と名前空間軸での包含で要素に関連しています。 属性と名前空間軸が直接正本の要素の開始タグに現れるテキストに対応しないかもしれないことに注意してください。
Note: An element has attribute nodes to represent the non-namespace
attribute declarations appearing in its start tag as well as
nodes to represent the default attributes.
以下に注意してください。 要素で、非名前空間属性宣言を表す属性ノードは、ノードと同様に省略時の属性を表すために開始タグに現れます。
By virtue of the XPath data model, XML canonicalization is namespace-aware [Names]. However, it cannot and therefore does not account for namespace equivalencies using namespace prefix rewriting (see explanation in Section 4). In the XPath data model, each element and attribute has a name returned by the function name() which can, at the discretion of the application, be the QName appearing in the original document. XML canonicalization REQUIRES that the XML processor retain sufficient information such that the QName of the element as it appeared in the original document can be provided.
XPathデータモデルによる、XML canonicalizationは名前空間意識しています[名前]。 そして、しかしながら、そうすることができない、したがって、名前空間接頭語の書き直し(セクション4で説明を見る)を使用することで名前空間equivalenciesの原因になりません。 XPathデータモデルでは、各要素と属性で、アプリケーションの裁量で正本に現れるQNameであるかもしれない機能名()で名前を返します。 XML canonicalization REQUIRES、XMLプロセッサは、正本に現れたので要素のQNameを提供できるように十分な情報を保有します。
Note: An element E has namespace nodes that represent its namespace
declarations as well as any namespace declarations made by its
ancestors that have not been overridden in E's declarations,
the default namespace if it is non-empty, and the declaration
of the prefix xml. nn Note: This specification supports the
recent XML plenary decision to
deprecate relative namespace URIs as follows: implementations
of XML canonicalization MUST report an operation failure on
documents containing relative namespace URIs. XML
canonicalization MUST NOT be implemented with an XML parser
that converts relative URIs to absolute URIs.
以下に注意してください。 要素Eには、それが非空であるなら宣言がEの宣言、デフォルト名前空間でくつがえされていない先祖で作ったどんな名前空間と同様に名前空間宣言、および接頭語xml. nn Noteの宣言を表す名前空間ノードがあります: この仕様は以下の相対的な名前空間URIを非難するという最近のXML絶対的な決定をサポートします: XML canonicalizationの実装は相対的な名前空間URIを含むドキュメントに関して操作失敗を報告しなければなりません。 相対的なURIを絶対URIに変換するXMLパーサでXML canonicalizationを実装してはいけません。
Character content is represented in the XPath data model with text nodes. All consecutive characters are placed into a single text node. Furthermore, the text node's characters are represented in the UCS character domain. The XML canonicalization method does not perform character model normalization (see explanation in Section 4). However, the XML processor used to prepare the XPath data model input
キャラクター内容はテキストノードがあるXPathデータモデルで表されます。 すべての連続したキャラクタがただ一つのテキストノードに置かれます。 その上、テキストノードのキャラクタはUCSキャラクタドメインで代理をされます。 XML canonicalizationメソッドはキャラクタモデル正常化を実行しません(セクション4で説明を見てください)。 しかしながら、XMLプロセッサは以前はよくXPathデータモデル入力を準備していました。
Boyer Informational [Page 8] RFC 3076 Canonical XML March 2001
2001年の[8ページ]RFC3076の正準なXML行進の情報のボワイエ
is REQUIRED to use Normalization Form C [NFC, NFC-Corrigendum] when converting an XML document to the UCS character domain from any encoding that is not UCS-based (currently, UCS-based encodings include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and UCS-4).
REQUIREDはそれをコード化しながらXMLドキュメントをいずれからもUCSキャラクタドメインに変換するのがUCSベースでないNormalization Form C[NFC、NFC-間違い]を使用することになっています。そして、(現在UCSベースのencodingsがUTF-8、UTF-16、UTF-16BEとUTF-16LE、UCS-2を含んでいる、UCS-4)
Since XML canonicalization converts an XPath node-set into a canonical form, the first parameter MUST either be an XPath node-set or it must be converted from an octet stream to a node-set by performing the XML processing necessary to create the XPath nodes described above, then setting an initial XPath evaluation context of:
XML canonicalizationがXPathノードセットを標準形に変換するので、最初のパラメタはXPathノードセットであるに違いありませんか上で説明されたXPathノードを作成するのに必要なXML処理を実行することによって、八重奏ストリームからノードセットまでそれを変換しなければなりません、次に、以下の初期のXPath評価関係を設定して
* A context node, initialized to the root node of the input XML
document.
* A context position, initialized to 1.
* A context size, initialized to 1.
* Any library of functions conforming to the XPath Recommendation.
* An empty set of variable bindings.
* An empty set of namespace declarations.
* 入力XMLドキュメントの根のノードに初期化された文脈ノード。 * 1に初期化された文脈位置。 * 1に初期化された文脈サイズ。 * XPath Recommendationに従う機能のどんなライブラリ。 * 変項束縛の空集合。 * 名前空間宣言の空集合。
and evaluating the following default expression:
以下のデフォルト式を評価します:
Comment Parameter Value Default XPath Expression
----------------------- ------------------------
コメントパラメタ値のデフォルトXPath式----------------------- ------------------------
Without (false):
(//. | //@* |//namespace::*)[not(self::comment())]
(誤っている)なしで: (//| //@* | //名前空間: : *)[(自己: : コメント())]
With (true):
(//. | //@* | //namespace::*)
(本当)で: (//| //@* | //名前空間: : *)
The expressions in this table generate a node-set containing every node of the XML document (except the comments if the comment parameter value is false).
XMLドキュメントのあらゆるノードを含んでいて、このテーブルの式はノードセットを生成します(コメントを除いて、コメントパラメタであるなら、値は誤っています)。
If the input is an XPath node-set, then the node-set must explicitly
contain every node to be rendered to the canonical form. For
example, the result of the XPath expression id("E") is a node-set
containing only the node corresponding to the element with an ID
attribute value of "E". Since none of its descendant nodes,
attribute nodes and namespace nodes are in the set, the canonical
form would consist solely of the element's start and end tags, less
the attribute and namespace declarations, with no internal content.
Section 3.7 exemplifies how to serialize an identified element along
with its internal content, attributes and namespace declarations.
入力がXPathノードセットであるなら、ノードセットは明らかに標準形に表されるあらゆるノードを含まなければなりません。 例えば、XPath式イド(「E」)の結果は「E」のID属性値に従った要素に対応するノードだけを含むノードセットです。 セットに派生ノード、属性ノード、および名前空間ノードのいずれもないので、標準形が唯一要素の始めと終了タグから成って、以下は、属性と名前空間宣言です、内部の内容なしで。 セクション3.7はどう内部の内容、属性、および名前空間宣言に伴う特定された要素を連載するかを例示します。
Boyer Informational [Page 9] RFC 3076 Canonical XML March 2001
2001年の[9ページ]RFC3076の正準なXML行進の情報のボワイエ
2.2 Document Order
2.2 ドキュメントオーダー
Although an XPath node-set is defined to be unordered, the XPath 1.0 Recommendation [XPath] defines the term document order to be the order in which the first character of the XML representation of each node occurs in the XML representation of the document after expansion of general entities, except for namespace and attribute nodes whose document order is application-dependent.
XPathノードセットは順不同のである定義されますが、XPath1.0Recommendation[XPath]はそれぞれのノードのXML表現の最初のキャラクタが一般実体の拡張の後にドキュメントのXML表現で起こる注文である用語ドキュメント命令を定義します、ドキュメントオーダーがアプリケーション依存している名前空間と属性ノードを除いて。
The XML canonicalization method processes a node-set by imposing the following additional document order rules on the namespace and attribute nodes of each element:
XML canonicalizationメソッドは以下の追加ドキュメントオーダー規則をそれぞれの要素の名前空間と属性ノードに課すことによって、ノードセットを処理します:
* An element's namespace and attribute nodes have a document
order position greater than the element but less than any child
node of the element.
* Namespace nodes have a lesser document order position than
attribute nodes.
* An element's namespace nodes are sorted lexicographically by
local name (the default namespace node, if one exists, has no
local name and is therefore lexicographically least).
* An element's attribute nodes are sorted lexicographically with
namespace URI as the primary key and local name as the
secondary key (an empty namespace URI is lexicographically
least).
* An element's namespace and attribute nodes have a document order position greater than the element but less than any child node of the element. * Namespace nodes have a lesser document order position than attribute nodes. * An element's namespace nodes are sorted lexicographically by local name (the default namespace node, if one exists, has no local name and is therefore lexicographically least). * An element's attribute nodes are sorted lexicographically with namespace URI as the primary key and local name as the secondary key (an empty namespace URI is lexicographically least).
Lexicographic comparison, which orders strings from least to greatest alphabetically, is based on the UCS codepoint values, which is equivalent to lexicographic ordering based on UTF-8.
Lexicographic comparison, which orders strings from least to greatest alphabetically, is based on the UCS codepoint values, which is equivalent to lexicographic ordering based on UTF-8.
2.3 Processing Model
2.3 Processing Model
The XPath node-set is converted into an octet stream, the canonical form, by generating the representative UCS characters for each node in the node-set in ascending document order, then encoding the result in UTF-8 (without a leading byte order mark). No node is processed more than once. Note that processing an element node E includes the processing of all members of the node-set for which E is an ancestor. Therefore, directly after the representative text for E is generated, E and all nodes for which E is an ancestor are removed from the node-set (or some logically equivalent operation occurs such that the node-set's next node in document order has not been processed). Note, however, that an element node is not removed from the node-set until after its children are processed.
The XPath node-set is converted into an octet stream, the canonical form, by generating the representative UCS characters for each node in the node-set in ascending document order, then encoding the result in UTF-8 (without a leading byte order mark). No node is processed more than once. Note that processing an element node E includes the processing of all members of the node-set for which E is an ancestor. Therefore, directly after the representative text for E is generated, E and all nodes for which E is an ancestor are removed from the node-set (or some logically equivalent operation occurs such that the node-set's next node in document order has not been processed). Note, however, that an element node is not removed from the node-set until after its children are processed.
The result of processing a node depends on its type and on whether or not it is in the node-set. If a node is not in the node-set, then no text is generated for the node except for the result of processing
The result of processing a node depends on its type and on whether or not it is in the node-set. If a node is not in the node-set, then no text is generated for the node except for the result of processing
Boyer Informational [Page 10] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 10] RFC 3076 Canonical XML March 2001
its namespace and attribute axes (elements only) and its children (elements and the root node). If the node is in the node-set, then text is generated to represent the node in the canonical form in addition to the text generated by processing the node's namespace and attribute axes and child nodes.
its namespace and attribute axes (elements only) and its children (elements and the root node). If the node is in the node-set, then text is generated to represent the node in the canonical form in addition to the text generated by processing the node's namespace and attribute axes and child nodes.
Note: The node-set is treated as a set of nodes, not a list of
subtrees. To canonicalize an element including its namespaces,
attributes, and content, the node-set must actually contain all
of the nodes corresponding to these parts of the document, not
just the element node.
Note: The node-set is treated as a set of nodes, not a list of subtrees. To canonicalize an element including its namespaces, attributes, and content, the node-set must actually contain all of the nodes corresponding to these parts of the document, not just the element node.
The text generated for a node is dependent on the node type and given in the following list:
The text generated for a node is dependent on the node type and given in the following list:
* Root Node- The root node is the parent of the top-level
document element. The result of processing each of its child
nodes that is in the node-set in document order. The root node
does not generate a byte order mark, XML declaration, nor
anything from within the document type declaration.
* Root Node- The root node is the parent of the top-level document element. The result of processing each of its child nodes that is in the node-set in document order. The root node does not generate a byte order mark, XML declaration, nor anything from within the document type declaration.
* Element Nodes- If the element is not in the node-set, then the
result is obtained by processing the namespace axis, then the
attribute axis, then processing the child nodes of the element
that are in the node-set (in document order). If the element
is in the node-set, then the result is an open angle bracket
(<), the element QName, the result of processing the namespace
axis, the result of processing the attribute axis, a close
angle bracket (>), the result of processing the child nodes of
the element that are in the node-set (in document order), an
open angle bracket, a forward slash (/), the element QName, and
a close angle bracket.
* Element Nodes- If the element is not in the node-set, then the result is obtained by processing the namespace axis, then the attribute axis, then processing the child nodes of the element that are in the node-set (in document order). If the element is in the node-set, then the result is an open angle bracket (<), the element QName, the result of processing the namespace axis, the result of processing the attribute axis, a close angle bracket (>), the result of processing the child nodes of the element that are in the node-set (in document order), an open angle bracket, a forward slash (/), the element QName, and a close angle bracket.
*
o Namespace Axis- Consider a list L containing only namespace
nodes in the axis and in the node-set in lexicographic order
(ascending). To begin processing L, if the first node is not
the default namespace node (a node with no namespace URI and
no local name), then generate a space followed by xmlns="" if
and only if the following conditions are met:
* o Namespace Axis- Consider a list L containing only namespace nodes in the axis and in the node-set in lexicographic order (ascending). To begin processing L, if the first node is not the default namespace node (a node with no namespace URI and no local name), then generate a space followed by xmlns="" if and only if the following conditions are met:
+ the element E that owns the axis is in the node-set
+ The nearest ancestor element of E in the node-set has a
default namespace node in the node-set (default namespace
nodes always have non-empty values in XPath)
+ the element E that owns the axis is in the node-set + The nearest ancestor element of E in the node-set has a default namespace node in the node-set (default namespace nodes always have non-empty values in XPath)
Boyer Informational [Page 11] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 11] RFC 3076 Canonical XML March 2001
The latter condition eliminates unnecessary occurrences of
xmlns="" in the canonical form since an element only receives
an xmlns="" if its default namespace is empty and if it has
an immediate parent in the canonical form that has a non-
empty default namespace. To finish processing L, simply
process every namespace node in L, except omit namespace node
with local name xml, which defines the xml prefix, if its
string value is http://www.w3.org/XML/1998/namespace.
The latter condition eliminates unnecessary occurrences of xmlns="" in the canonical form since an element only receives an xmlns="" if its default namespace is empty and if it has an immediate parent in the canonical form that has a non- empty default namespace. To finish processing L, simply process every namespace node in L, except omit namespace node with local name xml, which defines the xml prefix, if its string value is http://www.w3.org/XML/1998/namespace.
o Attribute Axis- In lexicographic order (ascending), process
each node that is in the element's attribute axis and in the
node-set.
o Attribute Axis- In lexicographic order (ascending), process each node that is in the element's attribute axis and in the node-set.
* Namespace Nodes- A namespace node N is ignored if the nearest
ancestor element of the node's parent element that is in the
node-set has a namespace node in the node-set with the same
local name and value as N. Otherwise, process the namespace
node N in the same way as an attribute node, except assign the
local name xmlns to the default namespace node if it exists (in
XPath, the default namespace node has an empty URI and local
name).
* Namespace Nodes- A namespace node N is ignored if the nearest ancestor element of the node's parent element that is in the node-set has a namespace node in the node-set with the same local name and value as N. Otherwise, process the namespace node N in the same way as an attribute node, except assign the local name xmlns to the default namespace node if it exists (in XPath, the default namespace node has an empty URI and local name).
* Attribute Nodes- a space, the node's QName, an equals sign, an
open quotation mark (double quote), the modified string value,
and a close quotation mark (double quote). The string value of
the node is modified by replacing all ampersands (&) with
&, all open angle brackets (<) with <, all quotation
mark (double quote) characters with ", and the whitespace
characters #x9, #xA, and #xD, with character references. The
character references are written in uppercase hexadecimal with
no leading zeroes (for example, #xD is represented by the
character reference 
).
* Attribute Nodes- a space, the node's QName, an equals sign, an open quotation mark (double quote), the modified string value, and a close quotation mark (double quote). The string value of the node is modified by replacing all ampersands (&) with &, all open angle brackets (<) with <, all quotation mark (double quote) characters with ", and the whitespace characters #x9, #xA, and #xD, with character references. The character references are written in uppercase hexadecimal with no leading zeroes (for example, #xD is represented by the character reference ).
* Text Nodes- the string value, except all ampersands are
replaced by &, all open angle brackets (<) are replaced by
<, all closing angle brackets (>) are replaced by >, and
all #xD characters are replaced by 
.
* Text Nodes- the string value, except all ampersands are replaced by &, all open angle brackets (<) are replaced by <, all closing angle brackets (>) are replaced by >, and all #xD characters are replaced by .
* Processing Instruction (PI) Nodes- The opening PI symbol (<?),
the PI target name of the node, a leading space and the string
value if it is not empty, and the closing PI symbol (?>). If
the string value is empty, then the leading space is not added.
Also, a trailing #xA is rendered after the closing PI symbol
for PI children of the root node with a lesser document order
than the document element, and a leading #xA is rendered before
the opening PI symbol of PI children of the root node with a
greater document order than the document element.
* Processing Instruction (PI) Nodes- The opening PI symbol (<?), the PI target name of the node, a leading space and the string value if it is not empty, and the closing PI symbol (?>). If the string value is empty, then the leading space is not added. Also, a trailing #xA is rendered after the closing PI symbol for PI children of the root node with a lesser document order than the document element, and a leading #xA is rendered before the opening PI symbol of PI children of the root node with a greater document order than the document element.
Boyer Informational [Page 12] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 12] RFC 3076 Canonical XML March 2001
* Comment Nodes- Nothing if generating canonical XML without
comments. For canonical XML with comments, generate the
opening comment symbol (<!--), the string value of the node,
and the closing comment symbol (-->). Also, a trailing #xA is
rendered after the closing comment symbol for comment children
of the root node with a lesser document order than the document
element, and a leading #xA is rendered before the opening
comment symbol of comment children of the root node with a
greater document order than the document element. (Comment
children of the root node represent comments outside of the
top-level document element and outside of the document type
declaration.)
* Comment Nodes- Nothing if generating canonical XML without comments. For canonical XML with comments, generate the opening comment symbol (<!--), the string value of the node, and the closing comment symbol (-->). Also, a trailing #xA is rendered after the closing comment symbol for comment children of the root node with a lesser document order than the document element, and a leading #xA is rendered before the opening comment symbol of comment children of the root node with a greater document order than the document element. (Comment children of the root node represent comments outside of the top-level document element and outside of the document type declaration.)
The QName of a node is either the local name if the namespace prefix string is empty or the namespace prefix, a colon, then the local name of the element. The namespace prefix used in the QName MUST be the same one which appeared in the input document.
The QName of a node is either the local name if the namespace prefix string is empty or the namespace prefix, a colon, then the local name of the element. The namespace prefix used in the QName MUST be the same one which appeared in the input document.
2.4 Document Subsets
2.4 Document Subsets
Some applications require the ability to create a physical representation for an XML document subset (other than the one generated by default, which can be a proper subset of the document if the comments are omitted). Implementations of XML canonicalization that are based on XPath can provide this functionality with little additional overhead by accepting a node-set as input rather than an octet stream.
Some applications require the ability to create a physical representation for an XML document subset (other than the one generated by default, which can be a proper subset of the document if the comments are omitted). Implementations of XML canonicalization that are based on XPath can provide this functionality with little additional overhead by accepting a node-set as input rather than an octet stream.
The processing of an element node E MUST be modified slightly when an XPath node-set is given as input and the element's parent is omitted from the node-set. The method for processing the attribute axis of an element E in the node-set is enhanced. All element nodes along E's ancestor axis are examined for nearest occurrences of attributes in the xml namespace, such as xml:lang and xml:space (whether or not they are in the node-set). From this list of attributes, remove any that are in E's attribute axis (whether or not they are in the node- set). Then, lexicographically merge this attribute list with the nodes of E's attribute axis that are in the node-set. The result of visiting the attribute axis is computed by processing the attribute nodes in this merged attribute list.
The processing of an element node E MUST be modified slightly when an XPath node-set is given as input and the element's parent is omitted from the node-set. The method for processing the attribute axis of an element E in the node-set is enhanced. All element nodes along E's ancestor axis are examined for nearest occurrences of attributes in the xml namespace, such as xml:lang and xml:space (whether or not they are in the node-set). From this list of attributes, remove any that are in E's attribute axis (whether or not they are in the node- set). Then, lexicographically merge this attribute list with the nodes of E's attribute axis that are in the node-set. The result of visiting the attribute axis is computed by processing the attribute nodes in this merged attribute list.
Note: XML entities can derive application-specific meaning from
anywhere in the XML markup as well as by rules not expressed
in XML 1.0 and the Namespaces Recommendations. Clearly,
these rules cannot be specified in this document, so the
creator of the input node-set must be responsible for
preserving the information necessary to capture the full
semantics of the members of the resulting node-set.
Note: XML entities can derive application-specific meaning from anywhere in the XML markup as well as by rules not expressed in XML 1.0 and the Namespaces Recommendations. Clearly, these rules cannot be specified in this document, so the creator of the input node-set must be responsible for preserving the information necessary to capture the full semantics of the members of the resulting node-set.
Boyer Informational [Page 13] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 13] RFC 3076 Canonical XML March 2001
The canonical XML generated for an entire XML document is well- formed. The canonical form of an XML document subset may not be well-formed XML. However, since the canonical form may be subjected to further XML processing, most XPath node-sets provided for canonicalization will be designed to produce a canonical form that is a well-formed XML document or external general parsed entity. Whether from a full document or a document subset, if the canonical form is well-formed XML, then subsequent applications of the same XML canonicalization method to the canonical form make no changes.
The canonical XML generated for an entire XML document is well- formed. The canonical form of an XML document subset may not be well-formed XML. However, since the canonical form may be subjected to further XML processing, most XPath node-sets provided for canonicalization will be designed to produce a canonical form that is a well-formed XML document or external general parsed entity. Whether from a full document or a document subset, if the canonical form is well-formed XML, then subsequent applications of the same XML canonicalization method to the canonical form make no changes.
3. Examples of XML Canonicalization
3. Examples of XML Canonicalization
The examples in this section assume a non-validating processor, primarily so that a document type declaration can be used to declare entities as well as default attributes and attributes of various types (such as ID and enumerated) without having to declare all attributes for all elements in the document. As well, one example contains an element that deliberately violates a validity constraint (because it is still well-formed).
The examples in this section assume a non-validating processor, primarily so that a document type declaration can be used to declare entities as well as default attributes and attributes of various types (such as ID and enumerated) without having to declare all attributes for all elements in the document. As well, one example contains an element that deliberately violates a validity constraint (because it is still well-formed).
3.1 PIs, Comments, and Outside of Document Element
3.1 PIs, Comments, and Outside of Document Element
Input Document -------------- <?xml version="1.0"?>
Input Document -------------- <?xml version="1.0"?>
<?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>
<?xml-stylesheet href="doc.xsl" type="text/xsl" ?>
<!DOCTYPE doc SYSTEM "doc.dtd">
<!DOCTYPE doc SYSTEM "doc.dtd">
<doc>Hello, world!<!-- Comment 1 --></doc>
<doc>Hello, world!<!-- Comment 1 --></doc>
<?pi-without-data ?>
<?pi-without-data ?>
<!-- Comment 2 -->
<!-- Comment 2 -->
<!-- Comment 3 -->
<!-- Comment 3 -->
Canonical Form (uncommented)
----------------------------
<?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>
<doc>Hello, world!</doc>
<?pi-without-data?>
Canonical Form (uncommented) ---------------------------- <?xml-stylesheet href="doc.xsl" type="text/xsl" ?> <doc>Hello, world!</doc> <?pi-without-data?>
Boyer Informational [Page 14] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 14] RFC 3076 Canonical XML March 2001
Canonical Form (commented)
--------------------------
<?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>
<doc>Hello, world!<!-- Comment 1 --></doc>
<?pi-without-data?>
<!-- Comment 2 -->
<!-- Comment 3 -->
Canonical Form (commented) -------------------------- <?xml-stylesheet href="doc.xsl" type="text/xsl" ?> <doc>Hello, world!<!-- Comment 1 --></doc> <?pi-without-data?> <!-- Comment 2 --> <!-- Comment 3 -->
Demonstrates:
Demonstrates:
* Loss of XML declaration
* Loss of DTD
* Normalization of whitespace outside of document element (first
character of both canonical forms is '<'; single line breaks
separate PIs and comments outside of document element)
* Loss of whitespace between PITarget and its data * Retention of
whitespace inside PI data
* Comment removal from uncommented canonical form, including
delimiter for comments outside document element (the last
character in both canonical forms is '>')
* Loss of XML declaration * Loss of DTD * Normalization of whitespace outside of document element (first character of both canonical forms is '<'; single line breaks separate PIs and comments outside of document element) * Loss of whitespace between PITarget and its data * Retention of whitespace inside PI data * Comment removal from uncommented canonical form, including delimiter for comments outside document element (the last character in both canonical forms is '>')
3.2 Whitespace in Document Content
3.2 Whitespace in Document Content
Input Document
--------------
<doc>
<clean> </clean>
<dirty> A B </dirty>
<mixed>
A
<clean> </clean>
B
<dirty> A B </dirty>
C
</mixed>
</doc>
Input Document -------------- <doc> <clean> </clean> <dirty> A B </dirty> <mixed> A <clean> </clean> B <dirty> A B </dirty> C </mixed> </doc>
Canonical Form
--------------
<doc>
<clean> </clean>
<dirty> A B </dirty>
<mixed>
A
<clean> </clean>
B
<dirty> A B </dirty>
Canonical Form -------------- <doc> <clean> </clean> <dirty> A B </dirty> <mixed> A <clean> </clean> B <dirty> A B </dirty>
Boyer Informational [Page 15] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 15] RFC 3076 Canonical XML March 2001
C
</mixed>
</doc>
C </mixed> </doc>
Demonstrates:
Demonstrates:
* Retain all whitespace between consecutive start tags, clean or
dirty
* Retain all whitespace between consecutive end tags, clean or
dirty
* Retain all whitespace between end tag/start tag pair, clean or
dirty
* Retain all whitespace in character content, clean or dirty
* Retain all whitespace between consecutive start tags, clean or dirty * Retain all whitespace between consecutive end tags, clean or dirty * Retain all whitespace between end tag/start tag pair, clean or dirty * Retain all whitespace in character content, clean or dirty
Note: In this example, the input document and canonical form are
identical. Both end with '>' character.
Note: In this example, the input document and canonical form are identical. Both end with '>' character.
3.3 Start and End Tags
3.3 Start and End Tags
Input Document
--------------
<!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>
Input Document -------------- <!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>
Canonical Form -------------- <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"
Canonical Form -------------- <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"
Boyer Informational [Page 16] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 16] RFC 3076 Canonical XML March 2001
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>
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>
Demonstrates:
Demonstrates:
* Empty element conversion to start-end tag pair
* Normalization of whitespace in start and end tags
* Relative order of namespace and attribute axes
* Lexicographic ordering of namespace and attribute axes
* Retention of namespace prefixes from original document
* Elimination of superfluous namespace declarations
* Addition of default attribute
* Empty element conversion to start-end tag pair * Normalization of whitespace in start and end tags * Relative order of namespace and attribute axes * Lexicographic ordering of namespace and attribute axes * Retention of namespace prefixes from original document * Elimination of superfluous namespace declarations * Addition of default attribute
Note: Some start tags in the canonical form are very long, but each
start tag in this example is entirely on a single line.
Note: Some start tags in the canonical form are very long, but each start tag in this example is entirely on a single line.
Note: In e5, b:attr precedes a:attr because the primary key is
namespace URI not namespace prefix, and attr2 precedes b:attr
because the default namespace is not applied to unqualified
attributes (so the namespace URI for attr2 is empty).
Note: In e5, b:attr precedes a:attr because the primary key is namespace URI not namespace prefix, and attr2 precedes b:attr because the default namespace is not applied to unqualified attributes (so the namespace URI for attr2 is empty).
3.4 Character Modifications and Character References
3.4 Character Modifications and Character References
Input Document -------------- <!DOCTYPE doc [ <!ATTLIST normId id ID #IMPLIED> <!ATTLIST normNames attr NMTOKENS #IMPLIED> ]> <doc> <text>First line
 Second line</text> <value>2</value> <compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]> </compute> <compute expr='value>"0" && value<"10" ?"valid":"error"'>valid</compute> <norm attr=' '   
	 ' '/> <normNames attr=' A   
	 B '/> <normId id=' '   
	 ' '/> </doc>
Input Document -------------- <!DOCTYPE doc [ <!ATTLIST normId id ID #IMPLIED> <!ATTLIST normNames attr NMTOKENS #IMPLIED> ]> <doc> <text>First line Second line</text> <value>2</value> <compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]> </compute> <compute expr='value>"0" && value<"10" ?"valid":"error"'>valid</compute> <norm attr=' ' ' '/> <normNames attr=' A B '/> <normId id=' ' ' '/> </doc>
Boyer Informational [Page 17] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 17] RFC 3076 Canonical XML March 2001
Canonical Form -------------- <doc> <text>First line
 Second line</text> <value>2</value> <compute>value>"0" && value<"10" ?"valid":"error" </compute> <compute expr="value>"0" && value<"10" ?" valid":"error"">valid</compute> <norm attr=" ' 
	 ' "></norm> <normNames attr="A 
	 B"></normNames> <normId id="' 
	 '"></normId> </doc>
Canonical Form -------------- <doc> <text>First line Second line</text> <value>2</value> <compute>value>"0" && value<"10" ?"valid":"error" </compute> <compute expr="value>"0" && value<"10" ?" valid":"error"">valid</compute> <norm attr=" ' ' "></norm> <normNames attr="A B"></normNames> <normId id="' '"></normId> </doc>
Demonstrates:
Demonstrates:
* Character reference replacement
* Attribute value delimiters set to quotation marks (double
quotes)
* Attribute value normalization
* CDATA section replacement
* Encoding of special characters as character references in
attribute values (&, <, ", 
, 
, 	)
* Encoding of special characters as character references in text
(&, <, >, 
)
* Character reference replacement * Attribute value delimiters set to quotation marks (double quotes) * Attribute value normalization * CDATA section replacement * Encoding of special characters as character references in attribute values (&, <, ", , , ) * Encoding of special characters as character references in text (&, <, >, )
Note: The last element, normId, is well-formed but violates a
validity constraint for attributes of type ID. For testing
canonical XML implementations based on validating processors,
remove the line containing this element from the input and
canonical form. In general, XML consumers should be
discouraged from using this feature of XML.
Note: The last element, normId, is well-formed but violates a validity constraint for attributes of type ID. For testing canonical XML implementations based on validating processors, remove the line containing this element from the input and canonical form. In general, XML consumers should be discouraged from using this feature of XML.
Note: Whitespace characters references other than   are not
affected by attribute value normalization [XML].
Note: Whitespace characters references other than are not affected by attribute value normalization [XML].
Note: In the canonical form, the value of the attribute named attr in
the element norm begins with a space, a single quote, then four
spaces before the first character reference.
Note: In the canonical form, the value of the attribute named attr in the element norm begins with a space, a single quote, then four spaces before the first character reference.
Note: The expr attribute of the second compute element contains no
line breaks.
Note: The expr attribute of the second compute element contains no line breaks.
Boyer Informational [Page 18] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 18] RFC 3076 Canonical XML March 2001
3.5 Entity References
3.5 Entity References
Input Document
--------------
<!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>
Input Document -------------- <!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>
<!-- Let world.txt contain "world" (excluding the quotes) -->
<!-- Let world.txt contain "world" (excluding the quotes) -->
Canonical Form (uncommented)
----------------------------
<doc attrExtEnt="entExt">
Hello, world!
</doc>
Canonical Form (uncommented) ---------------------------- <doc attrExtEnt="entExt"> Hello, world! </doc>
Demonstrates:
Demonstrates:
* Internal parsed entity reference replacement
* External parsed entity reference replacement (including
whitespace outside elements and PIs)
* External unparsed entity reference
* Internal parsed entity reference replacement * External parsed entity reference replacement (including whitespace outside elements and PIs) * External unparsed entity reference
3.6 UTF-8 Encoding
3.6 UTF-8 Encoding
Input Document -------------- <?xml version="1.0" encoding="ISO-8859-1"?> <doc>©</doc>
Input Document -------------- <?xml version="1.0" encoding="ISO-8859-1"?> <doc>©</doc>
Canonical Form -------------- <doc>#xC2#xA9</doc>
Canonical Form -------------- <doc>#xC2#xA9</doc>
Demonstrates:
Demonstrates:
* Effect of transcoding from a sample encoding to UTF-8
* Effect of transcoding from a sample encoding to UTF-8
Boyer Informational [Page 19] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 19] RFC 3076 Canonical XML March 2001
Note: The content of the doc element is NOT the string #xC2#xA9 but
rather the two octets whose hexadecimal values are C2 and A9,
which is the UTF-8 encoding of the UCS codepoint for the
copyright symbol (c).
Note: The content of the doc element is NOT the string #xC2#xA9 but rather the two octets whose hexadecimal values are C2 and A9, which is the UTF-8 encoding of the UCS codepoint for the copyright symbol (c).
3.7 Document Subsets
3.7 Document Subsets
Input Document
--------------
<!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>
Input Document -------------- <!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>
Document Subset Expression
--------------------------
(//. | //@* | //namespace::*)
[ <br/>
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())
]
Document Subset Expression -------------------------- (//. | //@* | //namespace::*) [ <br/> 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()) ]
Canonical Form -------------- <e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3 xmlns="" id="E3" xml:space="preserve"></e3></e1>
Canonical Form -------------- <e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3 xmlns="" id="E3" xml:space="preserve"></e3></e1>
Demonstrates:
Demonstrates:
* Empty default namespace propagation from omitted parent
element * Propagation of attributes in xml namespace in
document subsets * Persistence of omitted namespace
declarations in descendants
* Empty default namespace propagation from omitted parent element * Propagation of attributes in xml namespace in document subsets * Persistence of omitted namespace declarations in descendants
Note: In the document subset expression, the subexpression (//. |
//@* | //namespace::*) selects all nodes in the input document,
subjecting each to the predicate expression in square brackets.
The expression is true for e1 and its implicit namespace nodes,
and it is true if the element identified by E3 is in the
Note: In the document subset expression, the subexpression (//. | //@* | //namespace::*) selects all nodes in the input document, subjecting each to the predicate expression in square brackets. The expression is true for e1 and its implicit namespace nodes, and it is true if the element identified by E3 is in the
Boyer Informational [Page 20] RFC 3076 Canonical XML March 2001
Boyer Informational [Page 20] RFC 3076 Canonical XML March 2001
ancestor-or-self path of the context node (such that ancestor-
or-self stays the same size under union with the element
identified by E3).
ancestor-or-self path of the context node (such that ancestor- or-self stays the same size under union with the element identified by E3).
Note: The canonical form contains no line delimiters.
Note: The canonical form contains no line delimiters.
4. Resolutions
4. Resolutions
This section discusses a number of key decision points as well as a rationale for each decision. Although this specification now defines XML canonicalization in terms of the XPath data model rather than XML Infoset, the canonical form described in this document is quite similar in most respects to the canonical form described in the January 2000 Canonical XML draft [C14N-20000119]. However, some differences exist, and a number of the subsections discuss the changes.
This section discusses a number of key decision points as well as a rationale for each decision. Although this specification now defines XML canonicalization in terms of the XPath data model rather than XML Infoset, the canonical form described in this document is quite similar in most respects to the canonical form described in the January 2000 Canonical XML draft [C14N-20000119]. However, some differences exist, and a number of the subsections discuss the changes.
4.1 No XML Declaration
4.1 No XML Declaration
The XML declaration, including version number and character encoding is omitted from the canonical form. The encoding is not needed since the canonical form is encoded in UTF-8. The version is not needed since the absence of a version number unambiguously indicates XML 1.0.
XML宣言であり、バージョン番号と文字符号化を含んでいるのは標準形から省略されます。 標準形がUTF-8でコード化されるので、コード化は必要ではありません。 バージョン番号の欠如が明白にXML1.0を示すので、バージョンは必要ではありません。
Future versions of XML will be required to include an XML declaration to indicate the version number. However, canonicalization method described in this specification may not be applicable to future versions of XML without some modifications. When canonicalization of a new version of XML is required, this specification could be updated to include the XML declaration as presumably the absence of the XML declaration from the XPath data model can be remedied by that time (e.g., by reissuing a new XPath based on the Infoset data model).
XMLの将来のバージョンが、バージョン番号を示すXML宣言を含むのに必要でしょう。 しかしながら、この仕様で説明されたcanonicalizationメソッドは何らかの変更なしでXMLの将来のバージョンに適切でないかもしれません。 XMLの新しいバージョンのcanonicalizationを必要とするとき、おそらく、その時(例えば、Infosetデータモデルに基づく新しいXPathを再発行するのによる)までにXPathデータモデルからのXML宣言の欠如を改善できるようにXML宣言を含むようにこの仕様をアップデートできました。
4.2 No Character Model Normalization
4.2 キャラクターモデル正常化がありません。
The Unicode standard [Unicode] allows multiple different representations of certain "precomposed characters" (a simple example is +U00E7, "LATIN SMALL LETTER C WITH CEDILLA"). Thus two XML documents with content that is equivalent for the purposes of most applications may contain differing character sequences. The W3C is preparing a normalized representation [CharModel]. The C14N-20000119 Canonical XML draft used this normalized form. However, many XML 1.0 processors do not perform this normalization. Furthermore, applications that must solve this problem typically enforce character model normalization at all times starting when character content is created in order to avoid processing failures that could otherwise result (e.g., see example from Cowan). Therefore, character model
ユニコード規格[ユニコード]はある「前構成されたキャラクタ」(+がU00E7、「セディーユがあるラテン語の小文字C」であるという簡単な例)の複数の異なった表現を許容します。 したがって、ほとんどのアプリケーションの目的のために同等な内容がある2通のXMLドキュメントが異なったキャラクタシーケンスを含むかもしれません。 W3Cは正常にされた表現[CharModel]を準備しています。 C14N-20000119 Canonical XML草稿はこの正規形を使用しました。 しかしながら、多くのXML1.0に、プロセッサはこの正常化を実行しません。 その上、この問題を解決しなければならないアプリケーションがキャラクタ内容がそうでなければ結果として生じることができた失敗を処理するのを避けるために作成されるとき(例えば、カウァンから例を見てください)いつも始まるキャラクタモデル正常化を通常実施します。 したがって、キャラクタモデル
Boyer Informational [Page 21] RFC 3076 Canonical XML March 2001
2001年の[21ページ]RFC3076の正準なXML行進の情報のボワイエ
normalization has been moved out of scope for XML canonicalization. However, the XML processor used to prepare the XPath data model input is required (by the Data Model) to use Normalization Form C [NFC, NFC-Corrigendum] when converting an XML document to the UCS character domain from any encoding that is not UCS-based (currently, UCS-based encodings include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and UCS-4).
正常化はXML canonicalizationのために範囲から動かされました。 しかしながら、XPathデータモデル入力を準備するのに使用されるXMLプロセッサが、それをコード化しながらXMLドキュメントをいずれからもUCSキャラクタドメインに変換するのがUCSベースでないNormalization Form C[NFC、NFC-間違い]を使用するのに必要です(Data Model)。そして、(現在UCSベースのencodingsがUTF-8、UTF-16、UTF-16BEとUTF-16LE、UCS-2を含んでいる、UCS-4)
4.3 Handling of Whitespace Outside Document Element
4.3 空白外部ドキュメント要素の取り扱い
The C14N-20000119 Canonical XML draft placed a #xA after each PI outside of the document element as well as a #xA after the end tag of the document element. The method in this specification performs the same function except for omitting the final #xA after the last PI (or comment or end tag of the document element). This technique ensures that PI (and comment) children of the root are separated from markup by a line feed even if root node or the document element are omitted from the output node-set.
C14N-20000119 Canonical XML草稿は#xAと同様にドキュメント要素に関する終了タグの後のドキュメント要素の外に各PIの後に#xAを置きました。 この仕様によるメソッドは最後のPI(または、ドキュメント要素に関するコメントか終了タグ)の後に最終的な#xAを省略するのを除いた同じ機能を実行します。 このテクニックは、根のノードかドキュメント要素が出力ノードセットから省略されても根のPI(コメントする)子供がマーク付けと改行で切り離されるのを確実にします。
4.4 No Namespace Prefix Rewriting
4.4 名前空間接頭語の書き直さないこと
The C14N-20000119 Canonical XML draft described a method for rewriting namespace prefixes such that two documents having logically equivalent namespace declarations would also have identical namespace prefixes. The goal was to eliminate dependence on the particular namespace prefixes in a document when testing for logical equivalence. However, there now exist a number of contexts in which namespace prefixes can impart information value in an XML document. For example, an XPath expression in an attribute value or element content can reference a namespace prefix. Thus, rewriting the namespace prefixes would damage such a document by changing its meaning (and it cannot be logically equivalent if its meaning has changed).
C14N-20000119 Canonical XML草稿はまた、論理的に同等な名前空間宣言を持っている2通のドキュメントが同じ名前空間接頭語を持つように名前空間接頭語を書き直すためのメソッドを説明しました。 論理的等値がないかどうかテストするとき、目標はドキュメントの特定の名前空間接頭語への依存をなくしました。 しかしながら、名前空間接頭語がXMLドキュメントの情報価値を伝達できる多くの文脈が現在、存在します。 例えば、属性値か要素含有量のXPath式は名前空間が前に置く参照をそうすることができます。 したがって、名前空間接頭語を書き直すと、そのようなドキュメントは、意味を変えることによって、破損するでしょう(意味が変化したなら、論理的に同等であるはずがありません)。
More formally, let D1 be a document containing an XPath in an attribute value or element content that refers to namespace prefixes used in D1. Further assume that the namespace prefixes in D1 will all be rewritten by the canonicalization method. Let D23D D1, then modify the namespace prefixes in D2 and modify the XPath expression's references to namespace prefixes such that D2 and D1 remain logically equivalent. Since namespace rewriting does not include occurrences of namespace references in attribute values and element content, the canonical form of D1 does not equal the canonical form of D2 because the XPath will be different. Thus, although namespace rewriting normalizes the namespace declarations, the goal eliminating dependence on the particular namespace prefixes in the document is not achieved.
より正式に、D1が属性値にXPathを含むドキュメントかD1で使用される名前空間接頭語を示す要素含有量であることをさせてください。 D1の名前空間接頭語がcanonicalizationメソッドですべて書き直されるとさらに仮定してください。 D23D D1をさせてください、そして、次に、D2の名前空間接頭語を変更してください、そして、D2とD1が論理的に同等なままで残るように、名前空間接頭語のXPath式の参照を変更してください。 以来、名前空間の書き直しは属性値と要素含有量における、名前空間参照の発生を含まないで、またXPathが異なるので、D1の標準形はD2の標準形と等しくはありません。 したがって、名前空間ですが、書き直しは名前空間宣言を正常にして、ドキュメントの特定の名前空間接頭語への依存を根絶する目標は達成されません。
Boyer Informational [Page 22] RFC 3076 Canonical XML March 2001
2001年の[22ページ]RFC3076の正準なXML行進の情報のボワイエ
Moreover, it is possible to prove that namespace rewriting is harmful, rather than simply ineffective. Let D1 be a document containing an XPath in an attribute value or element content that refers to namespace prefixes used in D1. Further assume that the namespace prefixes in D1 will all be rewritten by the canonicalization method. Now let D2 be the canonical form of D1. Clearly, the canonical forms of D1 and D2 are equivalent (since D2 is the canonical form of the canonical form of D1), yet D1 and D2 are not logically equivalent because the aforementioned XPath works in D1 and doesn't work in D2.
そのうえ、単に効力がないというよりむしろ名前空間の書き直しが有害であると立証するのは可能です。 D1が属性値にXPathを含むドキュメントかD1で使用される名前空間接頭語を示す要素含有量であることをさせてください。 D1の名前空間接頭語がcanonicalizationメソッドですべて書き直されるとさらに仮定してください。 今度は、D2がD1の標準形であることをさせてください。 明確に、D1とD2の標準形が同等である(D2がD1の標準形の標準形であるので)、しかし、前述のXPathがD1で働いていて、D2で働いていないので、D1とD2は論理的に同等ではありません。
Note that an argument similar to this can be leveled against the XML canonicalization method based on any of the cases in the Limitations, the problems cannot easily be fixed in those cases, whereas here we have an opportunity to avoid purposefully introducing such a limitation.
Limitationsのケースのいずれにも基づくXML canonicalizationメソッドに対してこれと同様の議論を平らにすることができますが、それらの場合では容易に問題を修正できませんが、ここに、私たちが故意にそのような制限を導入するのを避ける機会を持っていることに注意してください。
Applications that must test for logical equivalence must perform more sophisticated tests than mere octet stream comparison. However, this is quite likely to be necessary in any case in order to test for logical equivalencies based on application rules as well as rules from other XML-related recommendations, working drafts, and future works.
論理的等値がないかどうか検査されなければならないアプリケーションは単なる八重奏ストリーム比較より洗練されたテストを実行しなければなりません。 しかしながら、これは、他のXML関連の推薦、概要版、および将来の作品からの規則と同様にアプリケーション規則に基づく論理的なequivalenciesがないかどうかテストするためにかなりどのような場合でも、必要である傾向があります。
4.5 Order of Namespace Declarations and Attributes
4.5 名前空間宣言と属性の注文
The C14N-20000119 Canonical XML draft alternated between namespace declarations and attribute declarations. This is part of the namespace prefix rewriting scheme, which this specification eliminates. This specification follows the XPath data model of putting all namespace nodes before all attribute nodes.
C14N-20000119 Canonical XML草稿は名前空間宣言と属性宣言の間を行き来しました。 これはこの仕様が排除する体系を書き直す名前空間接頭語の一部です。 この仕様はすべての名前空間ノードをすべての属性ノードの前に置くXPathデータモデルに従います。
4.6 Superfluous Namespace Declarations
4.6 余計な名前空間宣言
Unnecessary namespace declarations are not made in the canonical form. Whether for an empty default namespace, a non-empty default namespace, or a namespace prefix binding, the XML canonicalization method omits a declaration if it determines that the immediate parent element in the canonical form has an equivalent declaration in scope. The root document element is handled specially since it has no parent element. All namespace declarations in it are retained, except the declaration of an empty default namespace is automatically omitted.
標準形で不要な名前空間宣言をしません。 名前空間、非空のデフォルト名前空間、または名前空間が空のデフォルトのために結合を前に置くか否かに関係なく、標準形の即座の親元素が範囲に同等な宣言を持っていることを決定するなら、XML canonicalizationメソッドは宣言を省略します。 それには親元素が全くないので、特に、根のドキュメント要素は扱われます。 それのすべての名前空間宣言が保有されて、空のデフォルトの宣言を除いて、名前空間は自動的に省略されます。
Relative to the method of simply rendering the entire namespace context of each element, implementations are not hindered by more than a constant factor in processing time and memory use. The advantages include:
単にそれぞれの要素の全体の名前空間文脈を表すメソッドに比例して、実装は恒常的要因処理時間とメモリ使用における以上によって妨げられません。 利点は:
Boyer Informational [Page 23] RFC 3076 Canonical XML March 2001
2001年の[23ページ]RFC3076の正準なXML行進の情報のボワイエ
* Eliminates overrun of xmlns="" from canonical forms of
applications that may not even use namespaces, or support them
only minimally.
* Eliminates namespace declarations from elements where they may
not belong according to the application's content model,
thereby simplifying the task of reattaching a document type
declaration to a canonical form.
* 「xmlns=の超過を排除する、」 」 標準形のアプリケーションから、それは、名前空間を使用さえしませんし、またそれらを最少量でだけサポートしないかもしれません。 * アプリケーションの満足しているモデルに従ってそれらが属する、その結果、ドキュメント型の宣言を再付着させるタスクを簡素化することがないかもしれない要素から標準形までの名前空間宣言を排除します。
Note that in document subsets, an element with omissions from its ancestral element chain will be rendered to the canonical form with namespace declarations that may have been made in its omitted ancestors, thus preserving the meaning of the element.
ドキュメント部分集合では、先祖の要素チェーンからの省略を伴う要素が省略された先祖でされたかもしれない名前空間宣言と共に標準形に提供されることに注意してください、その結果、要素の意味を保存します。
4.7 Propagation of Default Namespace Declaration in Document Subsets
4.7 ドキュメント部分集合における、デフォルト名前空間宣言の伝播
The XPath data model represents an empty default namespace with the absence of a node, not with the presence of a default namespace node having an empty value. Thus, with respect to the fact that element e3 in the following examples is not namespace qualified, we cannot tell the difference between <e1 xmlns="a:b"><e2 xmlns=""><e3/></e2></e1> versus <e1 xmlns="a:b"><e2><e3 xmlns=""/></e2></e1>. All we know is that e3 was not namespace qualified on input, so we preserve this information on output if e2 is omitted so that e3 does not take on the default namespace qualification of e1.
XPathデータモデルは空の値を持っているデフォルト名前空間ノードの存在で表すのではなく、ノードの欠如で空のデフォルト名前空間を表します。 したがって、以下の例の要素e3が名前空間適切でないという事実に関して、私たちは、間に<e1 xmlnsが「a: b「><e2 xmlns=」「><e3/></e2></e1>対<e1 xmlns=」a: b「><e2><e3 xmlns=」」/></e2></e1>と等しいと違いに言うことができません。 e2が省略されるなら私たちが私たちが知っているすべてがe3が入力のときに適切な名前空間でなかったということであるので出力のこの情報を保存するので、e3はe1のデフォルト名前空間資格を帯びません。
4.8 Sorting Attributes by Namespace URI
4.8 名前空間URIは属性を分類すること。
Given the requirement to preserve the namespace prefixes declared in a document, sorting attributes with the prefix, rather than the namespace URI, as the primary key is viable and easier to implement.
名前空間を保存するという要件を考えて、接頭語はドキュメントで宣言しました、名前空間URIよりむしろ接頭語がある属性を分類して、主キーは実行可能であって、より実装しやすいとき。
However, the namespace URI was selected as the primary key because this is closer to the intent of the XML Names specification, which is to identify namespaces by URI and local name, not by a prefix and local name. The effect of the sort is to group together all attributes that are in the same namespace.
しかしながら、これが接頭語と地方名で特定するのではなく、URIと地方名で名前空間を特定することであるXML Names仕様の意図の、より近くにあるので、名前空間URIは主キーとして選定されました。 種類の効果は同じ名前空間にはあるすべての属性を一緒に分類することです。
Security Considerations
セキュリティ問題
Security issues are discussed in section 1.3.
セクション1.3で安全保障問題について議論します。
Boyer Informational [Page 24] RFC 3076 Canonical XML March 2001
2001年の[24ページ]RFC3076の正準なXML行進の情報のボワイエ
References
参照
[C14N-20000119] 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-20000119] 正準なXMLバージョン1.0、W3C作業草案。 T。 ロバの鳴き声、J.クラーク、J.タウバー、およびJ.カウァン。 2000年1月19日 http://www.w3.org/TR/2000/WD-xml-c14n- 20000119.html。
[CharModel] Working Draft. eds. Martin J. Durst, Francois
Yergeau, Misha Wolf, Asmus Freytag, Tex Texin.
http://www.w3.org/TR/charmod/.
[CharModel] Draft edsを扱います。 TexinフランソアYergeau、マーチンJ.があえてそうして、ミーシャがヴォルフであり、Asmusがフライタークであり、テックスは 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.
キャラクターモデル正常化の有害な効果に関する[カウァン]の例、XML署名ワーキンググループメールアーカイブにおける手紙。 ジョン・カウァン、2000年7月7日 http://lists.w3.org/Archives/Public/w3c-ietf- xmldsig/2000JulSep/0038.html。
[Infoset] XML Information Set, W3C Working Draft. John
Cowan, Richard Tobin.
http://www.w3.org/TR/xml-infoset.
W3C作業草案、[Infoset]XML情報はセットしました。 リチャード・トビンジョン・カウァン、 http://www.w3.org/TR/xml-infoset 。
[ISO-8859-1] ISO-8859-1 Latin 1 Character Set.
http://www.utoronto.ca/webdocs/HTMLdocs/
NewHTML/iso_table.html or
http://www.iso.ch/cate/cat.html.
[ISO-8859-1]ISO-8859-1ラテン1文字コード http://www.utoronto.ca/webdocs/HTMLdocs/ NewHTML/iso_table.htmlか http://www.iso.ch/cate/cat.html 。
[Keywords] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」という[キーワード]ブラドナー、S.、BCP14、RFC2119、1997年3月。
[Namespaces] Namespaces in XML, W3C Recommendation. eds.
Tim Bray, Dave Hollander, and Andrew Layman.
http://www.w3.org/TR/REC-xml-names/
XML、W3C Recommendation. edsの[名前空間]名前空間。 ティムBray、デーヴHollander、およびアンドリューLayman http://www.w3.org/TR/REC-xml-names/
[NFC] TR15, Unicode Normalization Forms. M. Davis,
M. Durst. Revision 18: November 1999.
http://www.unicode.org/unicode/reports/tr15/
tr15-18.html.
[NFC]TR15、ユニコード正常化は形成されます。あえて、M.デイヴィス、M.はそうしました。 改正18: 11月1999日の http://www.unicode.org/unicode/reports/tr15/ tr15-18.html。
[NFC-Corrigendum] NFC-Corrigendum. The Unicode Consortium.
http://www.unicode.org/unicode/uni2errata/
Normalization_Corrigendum.html.
[NFC-間違い] NFC-間違い。 共同体ユニコード http://www.unicode.org/unicode/uni2errata/ 正常化_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.
[ユニコード] ユニコードStandard、バージョン3.0。 ユニコード共同体。 ISBN0-201-61633-5 http://www.unicode.org/unicode/standard/ バージョン/Unicode3.0.html。
Boyer Informational [Page 25] RFC 3076 Canonical XML March 2001
2001年の[25ページ]RFC3076の正準なXML行進の情報のボワイエ
[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an
encoding of ISO 10646", RFC 2781, February
2000.
[UTF-16]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。
[UTF-8] Yergeau, F., "UTF-8, a transformation format
of ISO 10646", RFC 2279, January 1998.
[UTF-8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[URI]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[XBase] XML Base ed. Jonathan Marsh. 07 June 2000.
http://www.w3.org/TR/xmlbase/.
[XBase]XML基地の教育。 ジョナサンMarsh。 2000年6月7日 http://www.w3.org/TR/xmlbase/ 。
[XML] Extensible Markup Language (XML) 1.0 (Second
Edition), W3C=20 Recommendation. eds. Tim
Bray, Jean Paoli, C. M. Sperberg-McQueen and
Eve Maler. 6 October 2000.
http://www.w3.org/TR/REC-xml.
[XML]拡張マークアップ言語(XML)1.0(第2Edition)、W3C=20 Recommendation. eds。 ティムBray、ジーン・パオリ、C.M.Sperberg-マックィーン、およびイブMaler。 2000年10月6日 http://www.w3.org/TR/REC-xml 。
[XML DSig] Eastlake, D., Reagle, J. and D. Solo, "XML-
Signature Syntax and Processing", RFC 3075,
July 2000.
[XML DSig] イーストレーク、D.、Reagle、J.、D.独奏、および「XML署名構文と処理」、RFC3075、7月2000日
[XML Plenary Decision] 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.
相対的なURI References In名前空間宣言での[XML Plenary Decision]W3C XML Plenary Decision、W3C Document。 2000年9月11日 http://lists.w3.org/Archives/Public/xml- uri/2000Sep/0083.html。
[XPath] 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.
[XPath]XML Path Language(XPath)バージョン1.0、W3C Recommendation. eds。 ジェームス・クラークとスティーブンDeRose。 1999年11月16日 http://www.w3.org/TR/1999/REC-xpath-19991116 。
Author's Address
作者のアドレス
John Boyer PureEdge Solutions Inc.
ジョンボワイエPureEdgeソリューションInc.
Phone: 1-888-517-2675 EMail: jboyer@PureEdge.com
以下に電話をしてください。 1-888-517-2675 メールしてください: jboyer@PureEdge.com
Boyer Informational [Page 26] RFC 3076 Canonical XML March 2001
2001年の[26ページ]RFC3076の正準なXML行進の情報のボワイエ
Acknowledgements
承認
The following people provided valuable feedback that improved the quality of this specification:
以下の人々はこの仕様の品質を改良した有益なフィードバックを提供しました:
* Doug Bunting, Ariba
* John Cowan, Reuters
* Martin J. Durst, W3C
* Donald Eastlake 3rd, Motorola
* Merlin Hughes, Baltimore
* Gregor Karlinger, IAIK TU Graz
* Susan Lesch, W3C
* Jonathan Marsh, Microsoft
* Joseph Reagle, W3C
* Petteri Stenius, Done360
* Kent Tamura, IBM
* ダグBunting、アリバ*ジョン・カウァン、ロイター*マーチンJ.はあえてそうして、W3C*ドナルド・イーストレークは3番目です、モトローラ*マーリン・ヒューズ、ボルチモア*グレガーKarlinger、IAIK TUグラーツ*スーザン・レッシュ、W3C*ジョナサンMarsh、マイクロソフト*ジョゼフReagle、W3C*Petteri Stenius、Done360*ケント田村IBM
Boyer Informational [Page 27] RFC 3076 Canonical XML March 2001
2001年の[27ページ]RFC3076の正準なXML行進の情報のボワイエ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Boyer Informational [Page 28]
ボワイエInformationalです。[28ページ]
一覧
スポンサーリンク
