RFC 3076 - Canonical XML Version 1.0 日本語訳

URL : https://tools.ietf.org/html/rfc3076
タイトル : RFC 3076 - 正規のXMLバージョン1.0
翻訳編集 : 自動生成

Network Working Group                                           J. Boyer
Request for Comments: 3076                       PureEdge Solutions Inc.
Category: Informational                                       March 2001

                       Canonical XML Version 1.0

Status of this 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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2001）。全著作権所有。

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文書のセットの一部であるが、XMLにXML 1.0と名前空間によって許可構文変化に基づく物理的表現に変化します。この仕様は、物理的表現、許容変更を占めるXML文書の正則形式を生成するための方法を記載しています。二つの文書が同じ標準的な形式を持っている場合、いくつかの珍しい例に関する制限を除いて、2つの文書は、特定のアプリケーションのコンテキスト内で論理的に等価です。二つの文書が異なる標準的なフォームを持って、まだまだ一般化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. 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.

XML 1.0勧告[XML]は、XML文書と呼ばれるリソースのクラスの構文を指定します。 XML名前空間勧告[名前]は、XML文書のための追加的な構文とセマンティクスを指定します。これは、物理的な表現が異なるために、多くのアプリケーションの目的のために等価であるXML文書のために可能です。例えば、彼らは、そのエンティティの構造、属性の順序、および文字エンコーディングに異なる場合があります。 2つの文書が同一であるかどうか、またはアプリケーションがXML 1.0と名前空間によって許可された変換を除き、文書を変更していないかどうかを決定するための方法を確立するために、この仕様の目標です。

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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード] RFC 2119に記載されるように解釈されます。

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

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の正規化方法は、指定されたXML文書又は文書の部分集合の正則形式を生成し、この仕様で定義されたアルゴリズムです。用語XMLの正規化は、XML文書または文書のサブセットにXML正則化法を適用するプロセスを指します。

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, 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).

XPath 1.0の勧告[XPathの用語ノードセットを定義し、様々なタイプ（要素、属性、名前空間、テキスト、コメント、処理命令、および根）のノードの集合として入力XML文書を表現するためのデータ・モデルを指定します。ノードは、に含まれる又は発現の評価に基づいて、ノード集合から除外されます。本明細書中では、ノードセットが直接各ノードが（この意味では、それが正式な数学的な集合として使用されている）標準形式でレンダリングされるべきかどうかを示すために使用されます。セットから除外されたノードは、その親ノードがノードセットに含まれている場合であっても、生成される標準形式でレンダリングされていません。しかし、省略ノードが依然として（例えば、子孫の名前空間コンテキストを増強することにより）その子孫のレンダリングに影響を与えるかもしれません。

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.

XML 1.0勧告[XML]とXML勧告における名前空間[名]と同じ情報を表現するための複数の構文のメソッドを定義するため、XMLアプリケーションは、文書の情報内容に影響を与えない変更を自由を取る傾向があります。 XML正則化は、文書または文書サブセットの情報の内容が変更されたかどうかをテストする能力を必要とする用途に有用であるように設計されています。これは、アプリケーション処理の文書結果の標準形式でアプリケーション処理前の原稿の正規形を比較することによって行われます。

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によって論理的に等価であると定義されていることを条件とする1.0またはXML名前空間で。署名生成時、ダイジェストは、文書の正規形にわたって計算されます。文書は、その文書を読み取り、受信した文書の正則形式のダイジェストを計算することによって、署名を検証依拠当事者に転送されます。署名と依拠当事者によって計算されたダイジェストの等価性（ひいてはそれらが計算された上正則形式の等価）は、それが署名されたので、文書の情報内容が変更されていないことを保証します。

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 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.

2つのXML文書には、それにもかかわらず、論理的に等価な特定のアプリケーションコンテキスト内での情報の内容が異なる可能性があります。 2つのXML文書は、その標準的な形式が同一である場合、2つのXML文書があれば同等であることと、その標準的な形式が同一である場合にのみ、このような方法を確立するために、この作業の目的ではありません（余談このセクションに与えられた制限から）同等であるが、。このような方法は、そのような重要でない空白と同等のデータ（例えば、<色>ブラック</カラー>対<色> RGB（0,0,0）</色>を支配するもののようなアプリケーション固有のルールに部分的に達成不可能です）。他のW3C勧告およびワーキングドラフトによって確立された等価性もあります。これらの追加同値ルールの会計処理は、この仕事の範囲を超えています。彼らは、アプリケーションによって適用されるか、将来の仕様の対象になることができます。

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.ベースURIは、外部の一般の置換テキストに由来するコンテンツが解析され、特に内のエンティティは、2表記法を参照し、外部の解析対象外実体は、文書型宣言内の3属性タイプを参照します

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を付加し、アプリケーションにbase属性[知らせるxBase]：これらの問題の両方は、典型的には、XMLのサポートを追加することによって解決することができる塩基は、素子と外部エンティティ内のすべてのトップレベル要素を文書化する属性。また、アプリケーションは、多くの場合、前に正規の形式の必要性への相対URIを解決する機会を持っています。例えば、デジタル署名アプリケーションにおいて、文書は、多くの場合、検索と署名生成の前に処理されます。処理は、相対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 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文書を区別できないことを意味します。これは、ほとんどのXMLプロセッサは、現在の表記を破棄文書型宣言、エンティティの結合URIに、エンティティ名に属性値をバインドする属性タイプを捨てるからこそ珍しいケースです。複数の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.

第三のケースでは、属性タイプの損失は、種類に応じて異なる方法で標準形式に影響を与えることができます。 ID型の属性は、ID属性であることをやめます。したがって、動作するようにID（）関数の中止を使用して標準形式を参照任意のXPath式。属性タイプエンティティとエンティティは、このケースの一部ではありません。彼らは、上述した第2のケースで覆われています。列挙型の、タイプIDの属性は、IDREF、IDREFS、NMTOKEN、NMTOKENS、および表記は適切カノニカルフォームは、アプリケーション処理中に原稿を置き換える場合、属性値を変更する将来の試行中に拘束されません。アプリケーションは、適切な文書型宣言は、さらにXML処理で標準形式を使用する前に付加されることを確実にすることによって、この場合の難しさを回避することができます。属性リストは、通常、外部の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.

これらの制限が厳しくないものの場合、それはXMLの標準化の将来のバージョンでそれらを解決することが可能であろう、例えば、XPathの新しいバージョンは、現在W3Cで開発中のXML情報セット[インフォセット]に基づいて作成されました。

2. XML Canonicalization

2. XML正則

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.

XPath 1.0の勧告[たXPath]で定義されたデータモデルは、入力されたXML文書または文書の部分集合を表すために使用されます。実装は必要ではないがXPathの実装に基づくべきです。 XMLの正規化は、ノード集合の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正則化方法への入力の最初のパラメータは、XPathノード集合または整形式XML文書を含むオクテットストリームのいずれかです。実装は、オクテットストリーム入力をサポートしなければならないし、また、ノードセット入力を介して文書サブセット機能をサポートしなければなりません。 XPathノード集合の点で正規化を説明する目的のため、このセクションでは、オクテットストリームがXPathノード・セットに変換する方法を記載しています。

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正則化方法への入力の第2のパラメータは、コメントがXML正則化法により、標準形式の出力に含まれるべきかどうかを示すブールフラグです。標準形式は、入力ノードセット内のコメント・ノードに対応するコメントが含まれている場合、結果は、コメントとカノニカルXMLと呼ばれます。 XPathデータモデルは、文書型宣言（DTD）内に現れるコメントのコメントノードを作成しないことに注意してください。実装は、入力文書または文書のサブセットに登場したかもしれないすべてのコメントを除く標準的なXMLを生成することが可能であることが要求されています。コメントが正規のXMLのサポートが推奨されます。

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文書がノードセットに変換する必要がある場合、XPathは、XMLプロセッサが完全に文書を表現するために、そのデータモデルのノードを作成するために使用されることを要求します。 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正規化属性がその文字内容4.決意文字でCDATAセクションと解析された実体参照を交換3.値のフィード

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エンコーディングのサポートが推奨され、他のすべての文字エンコーディングはオプションです。

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文字を除く）保存されなければなりません。これは、外部エンティティ内のすべての空白文字を含んでいます。ルート文書要素の外側の空白は捨てなければなりません。

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.

注意：要素は、デフォルトの属性を表すために、その開始タグと同様に、ノードに出現する非namespace属性宣言を表現するために、ノードの属性があります。

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の正規化は、[名前]名前空間を認識しています。しかし、それは（第4節で説明を参照）書き換え名前空間接頭辞を使用して名前空間の等価性を考慮していないではないので、することができます。 XPathデータモデルでは、各要素および属性は、アプリケーションの裁量で、元の文書に出現するQNameとすることができる関数名（）によって返される名前を有します。 XMLの正規化は、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注：XML正則化の実装は相対的な名前空間URIを含む文書に動作不良を報告しなければなりません：この仕様は、次のように相対的な名前空間URIを廃止するために、最近のXML総会の決定をサポートしています。 XMLの正規化は、絶対URIに相対URIを変換するXMLパーサを用いて実装してはいけません。

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 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).

文字コンテンツは、テキストノードとXPathデータモデルで表現されます。すべての連続した文字は、単一のテキスト・ノードに配置されています。さらに、テキストノードの文字がUCS文字ドメインで表現されています。 XML正則化法は、キャラクタモデルの正規化を（第4節で説明を参照）を実行しません。しかし、XPathデータモデル入力を調製するために使用されるXMLプロセッサは、UCSベース現在（UCSない任意のエンコーディングからUCS文字ドメインにXMLドキュメントを変換するときに正規化形式C [NFC、NFC-正誤表]を使用する必要がありますベースのエンコーディングは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の正規化は、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の勧告に準拠した機能の任意のライブラリー。 *変数バインディングの空のセット。 *名前空間宣言の空のセット。

and evaluating the following default expression:

そして、次のデフォルトの式を評価します：

     Comment Parameter Value    Default XPath Expression
     -----------------------    ------------------------

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).

この表の式は、（コメントのパラメータの値が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式ID（「E」）の結果は、「E」のID属性値を持つ要素に対応する唯一のノードを含むノードセットです。その子孫ノードのどれもあるので、属性ノードと名前空間ノードは、セット内にある、正規形はなし内部のコンテンツと、要素の開始タグと終了タグのもっぱら以下の属性と名前空間宣言を構成されます。 3.7節は、属性と名前空間宣言、その内部のコンテンツと一緒に識別される要素をシリアル化する方法を例示しています。

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ノードセットを順不同であると定義されているが、XPath 1.0の勧告[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の正規化の方法は、処理ノード集合の各要素の名前空間と属性のノードで次の追加文書順規則を課すことによって。

       * 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.

アルファベット順に少なくともから最大までの文字列を注文辞書比較は、UTF-8に基づいて、辞書式順序に相当する、UCSコードポイント値に基づいています。

2.3 Processing Model

2.3処理モデル

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.

XPathノードセットは、ノードセット次いで、UTF-8における結果をコードする、昇順ドキュメント順に（なしの先頭バイト順マークの各ノードのための代表的なUCS文字を生成することによって、オクテットストリーム、標準形式に変換され）。どのノードが複数回処理されません。要素ノードEを処理するEが祖先されたノードセットのすべてのメンバーの処理を含むことに留意されたいです。したがって、直接Eのための代表的なテキストは、生成されたE及びEは、祖先であるすべてのノードがノードセットから除去（またはいくつかの論理的に等価な動作は文書順にノードセットの次のノードがなかったように発生された後処理されました）。要素ノードは、その子が処理された後まで、ノードセットから削除されていないこと、しかし、注意してください。

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 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.

注：ノードセットは、ノードの集合ではなく、サブツリーのリストとして扱われます。属性、内容、その名前空間を含む要素を正規化するために、ノードセットは、実際の文書だけでなく、要素ノードのこれらの部分に対応するノードのすべてを含まなければなりません。

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.

* 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.

*要素Nodes-要素がノードセット内にない場合、その結果は、名前空間軸を加工することにより得られ、その後、属性軸は、ドキュメント順にノード集合（にある要素の子ノードを処理します）。要素がノードセットにある場合、結果は開角ブラケット（<）は、要素のQName、名前空間軸を処理した結果、属性軸の処理結果、近いアングルブラケット（>）、（文書順に）ノード集合内にある要素の子ノードを処理した結果、開角ブラケット、スラッシュ（/）、要素のQName、および近い角度ブラケット。

* 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:

*名前空間Axis- oを辞書式順序（昇順）に軸におけるノードセット内の唯一の名前空間ノードを含むリストLを考えます。最初のノードは、デフォルトの名前空間ノードは、次の条件が満たされている場合に限り、「」=のxmlns続く空間を生成する（NO名前空間URIとローカル名を持つノード）がない場合、処理Lを開始します：

            + 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 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.

後者の条件は、そのデフォルトの名前空間が空の場合は「「要素が唯一のxmlns =を受けるため、正規の形式で」」=のxmlnsの不要な発生を排除し、それが空でないデフォルトの名前空間を持つ正規の形式で直接の親を持つ場合。 Lの処理を完了するために、単にその文字列値がhttp://www.w3.org/XML/1998/namespaceであれば、XMLプレフィックスを定義するローカル名のXMLと省略名前空間ノードを除いて、Lのすべての名前空間ノードを処理します。

o Attribute Axis- In lexicographic order (ascending), process each node that is in the element's attribute axis and in the node-set.

O辞書式順序（昇順）、プロセス要素の属性軸およびノードセットにある各ノードでAxis-属性。

* 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).

ノードセットにあるノードの親要素の最も近い祖先要素がノードセットそれ以外の場合はN.と同じローカル名と値で、プロセス内の名前空間ノードを持っている場合*名前空間ノードN Nodes-名前空間は無視されます（XPathの中に、デフォルトの名前空間ノードが空のURIとローカル名を持っている）が存在する場合、デフォルトの名前空間ノードにローカル名のxmlnsを割り当てる以外属性ノードと同様に、名前空間ノードN。

* 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 ).

*スペースNodes-属性、ノードのQNameに、看板、オープン引用符（二重引用符）、変更された文字列値、およびクローズ引用符（二重引用符）に等しいです。ノードの文字列値は、すべての開角括弧（<）と＆LT;、すべての引用符（二重引用符）と＆QUOT文字;,及び空白文字＃;,と＆＃038（＆）すべてのアンパサンドを置換することによって修飾されていますX9、の#xA、および#xD、文字参照を持ちます。文字参照がない先行ゼロで大文字進数で記述されている（例えば、#xDは文字参照＆#xDで表されます。）。

* 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 .

*すべてのアンパサンド以外の文字列値Nodes-テキストは、により置換されている＆＃038;、開いているすべての角括弧（<）によって置換されている＆LT ;,全て閉じ角括弧（>）＆gt;で、全ての#xDにより置換されています文字は＆#xDに置き換えられ;.

* 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.

*処理命令（PI）Nodes-オープニングPI記号（<？）、ノード、先頭のスペースと、それが空でない場合は、文字列値、終値PI記号（？のPIターゲット名>）。文字列値が空の場合、先頭のスペースは追加されません。また、後続の#xAは、文書要素より小さい文書順とルートノードのPIの子供のための閉鎖PIシンボルの後にレンダリングされ、そしてリーディングの#xAは、ルートノードのPI子供の開口PIシンボルと前にレンダリングされますドキュメント要素よりも大きい文書順。

* Comment Nodes- Nothing if generating canonical XML without comments. For canonical XML with comments, generate the opening 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.)

*コメントせずに正規のXMLを生成する場合Nodes-何もコメントしません。（<！ - 、ノードの文字列値、および終了コメント記号（） - >）のコメントと標準的なXMLの場合、開口部のコメント記号を生成します。また、後続の#xAは、文書要素より小さい文書順とルートノードのコメント子供のための閉鎖コメント記号の後にレンダリングされ、そしてリーディングの#xAは、ルートノードのコメント子供の開口コメントシンボルと前のレンダリングされドキュメント要素よりも大きい文書順。（ルートノードの子は、最上位の文書要素の外側と文書型宣言の外側のコメントを表すコメント）。

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.

ノードのQNameには、名前空間接頭辞の文字列が空の場合、またはローカル名のいずれかである名前空間接頭辞、コロン、要素のローカル名。 QNameのに使用される名前空間接頭辞は、入力された文書に登場したものと同じものでなければなりません。

2.4 Document Subsets

2.4ドキュメントのサブセット

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.

一部のアプリケーションは、（コメントは省略されている場合、文書の適切なサブセットすることができ、デフォルトで生成された1以外）は、XML文書のサブセットのための物理的な表現を作成する機能が必要です。 XPathのに基づいているXML正則化の実装は、入力ではなくオクテットストリームとしてノードセットを受け入れることにより、少ない追加のオーバヘッドでこの機能を提供することができます。

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.

XPathノード集合が入力として与えられ、要素の親がノードセットから省略されたときに要素ノードEの処理は、わずかに修正されなければなりません。ノード・セット内の要素Eの属性軸を処理するための方法が強化されます。ラングとxml：空間（これらはノード集合にあるか否か）Eの祖先軸に沿ってすべての要素ノードは、XMLなどのXML名前空間の属性の最も近い出現のために検査されます。この属性のリストから、Eの属性軸であることいずれかを削除（彼らはノードセットであるかどうか）。次に、辞書的にノード・セット内にあるEのattribute軸のノードと、この属性リストをマージします。属性軸を訪れるの結果は、このマージされた属性リストに属性ノードを処理することによって計算されます。

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.

注意：XMLエンティティはどこにでもXMLマークアップ内からだけでなく、XML 1.0では発現していないルールと名前空間の勧告によって、アプリケーション固有の意味を導き出すことができます。明らかに、これらのルールは、この文書で指定することはできませんので、入力ノードセットの作成者は、得られたノードセットのメンバーの完全なセマンティクスをキャプチャするために必要な情報を保存する責任である必要があります。

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.

XML文書全体のために生成された正規のXMLは、整形式です。 XML文書のサブセットの標準形は、整形式XMLではないかもしれません。カノニカルフォームはさらにXML処理を施すことができるので、正規化のために提供される最もXPathノードセットは、整形式XML文書または外部の一般的な構文解析エンティティである正則形式を生成するように設計されます。正則形式はXMLを十分に形成されている場合、完全な文書または文書の部分集合からかどうかは、標準形に同じXML正則化法の後続のアプリケーションは、何も変更をしません。

3. Examples of XML Canonicalization

XMLの正規化の3例

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).

文書型宣言は、すべてのすべての属性を宣言することなく、エンティティ、ならびにデフォルト属性と（例えば、IDや列挙など）様々なタイプの属性を宣言するために使用することができ、主にように、このセクションの例は、非検証プロセッサを想定しますドキュメント内の要素。同様に、一例としては、（それがまだ十分に形成されているので）意図的妥当性制約に違反する要素を含んでいます。

3.1 PIs, Comments, and Outside of Document Element

3.1主任研究者、コメント、およびドキュメント要素の外

   Input Document
   --------------
   <?xml version="1.0"?>

<?xml-stylesheet href="doc.xsl" type="text/xsl" ?>

<？xmlの-スタイルシートのhref = "doc.xsl" タイプ= "テキスト/ XSL"？>

<!DOCTYPE doc SYSTEM "doc.dtd">

<！DOCTYPEドキュメントシステム "doc.dtd">

<doc>Hello, world!</doc>

<ドキュメント>こんにちは、世界！<！ - コメント1 - > </ DOC>

<?pi-without-data ?>

<？PI-なしのデータ？>

<！ - コメント2 - >

<！ - コメント3 - >

   Canonical Form (uncommented)
   ----------------------------
   <?xml-stylesheet href="doc.xsl"
      type="text/xsl"   ?>
   <doc>Hello, world!</doc>
   <?pi-without-data?>

   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:

デモ：

       * 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空白

   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>

C </mixed> </doc>

C </混合> </ DOC>

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

Note: In this example, the input document and canonical form are identical. Both end with '>' character.

注：この例では、入力された文書と正則形式は同一です。どちらも、「>」文字で終わります。

3.3 Start and End Tags

3.3開始タグと終了タグ

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"

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 = ATTR2は= "すべて" B "私は"：ATTR = "ソート"：ATTR = "アウト"> </ E5> <E6ののxmlns： = "http://www.w3.org"> <E7のxmlns = "http://www.ietf.org"> <E8ののxmlns = ""> <E9ののxmlns：A = "のhttp：// WWW。 ietf.org」のattr = "デフォルト"> </ E9> </ E8> </ E7> </ E6> </ DOC>

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

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).

注意：E5で、B：ATTR aよりも先：attrの主キーは、名前空間URIない名前空間接頭辞で、ATTR2がBに先行しているため：デフォルトの名前空間が修飾されていない属性に適用されていないため、attrに（そうATTR2の名前空間URIは空です）。

3.4 Character Modifications and Character References

3.4文字の変更や文字参照

Input Document
--------------
<!DOCTYPE doc [
<!ATTLIST normId id ID #IMPLIED>
<!ATTLIST normNames attr NMTOKENS #IMPLIED>
]>
<doc>
   <text>First line&#x0d;&#10;Second line</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>

Canonical Form
--------------
<doc>
   <text>First line&#xD;
Second line</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>

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 (&amp;, &lt;, &quot;, &#xD;, &#xA;, &#x9;)
       * Encoding of special characters as character references in text
         (&amp;, &lt;, &gt;, &#xD;)

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.

注意：最後の要素、normIdは、整形式であるが、ID型の属性の妥当性制約に違反します。プロセッサの検証に基づいて、カノニカルXMLの実装をテストするため、入力と正則形式からこの要素を含む行を削除します。一般的には、XMLの消費者は、XMLのこの機能を使用してから落胆する必要があります。

Note: Whitespace characters references other than   are not affected by attribute value normalization [XML].

注意：＆＃のX20以外の空白文字参照を。属性値の正規化[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.

注：標準的な形式では、要素ノルムでattrに指定された属性の値は、4つのスペース最初の文字参照の前に、スペース、単一引用符で始まります。

Note: The expr attribute of the second compute element contains no line breaks.

注意：二計算要素のexprの属性には、改行が含まれていません。

3.5 Entity References

3.5実体参照

   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>

<！ - world.txtは、（引用符を除く） "世界" を含むましょう - >

   Canonical Form (uncommented)
   ----------------------------
   <doc attrExtEnt="entExt">
      Hello, world!
   </doc>

Demonstrates:

デモ：

       * 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エンコーディング

   Input Document
   --------------
   <?xml version="1.0" encoding="ISO-8859-1"?>
   <doc>&#169;</doc>

   Canonical Form
   --------------
   <doc>#xC2#xA9</doc>

Demonstrates:

デモ：

* Effect of transcoding from a sample encoding to UTF-8

* UTF-8へのサンプルのエンコーディングからのトランスコーディングの効果

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).

注：DOC要素の内容が文字列＃XC2＃xA9ではなく、むしろ、その進値著作権記号（c）のためのUCSコードポイントのUTF-8エンコーディングされC2とA9を、ある2つのオクテット。

3.7 Document Subsets

3.7ドキュメントのサブセット

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())
]

Canonical Form
--------------
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3
xmlns="" id="E3" xml:space="preserve"></e3></e1>

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

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 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).

注：文書のサブセットの式では、部分式（// | // @ * | //名前空間:: *）は、角括弧内の述語式にそれぞれを施す、入力文書内のすべてのノードを選択します。発現は、E1およびその暗黙の名前空間ノードに対して真であり、E3によって識別要素がコンテキストノードの祖先、または自己パス（祖先 - または - 自己と組合下で同じ大きさに留まるようにしている場合には真でありますE3で識別される要素）。

Note: The canonical form contains no line delimiters.

注意：正規の形式には行区切り文字が含まれていません。

4. Resolutions

4.決議

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.

このセクションでは、決定キーポイントの数ならびに各決定のための根拠を説明します。この仕様は、今ではなくXML情報セットよりも、XPathデータモデルの観点でXMLの標準化を定義しますが、この文書で説明した標準的な形式は、2000年1月CanonicalのXMLドラフトで説明した標準的な形式[C14N-20000119]に多くの点で非常に似ています。しかし、いくつかの違いが存在し、サブセクションの数は変化を議論します。

4.1 No XML Declaration

4.1 XML宣言ません

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でエンコードされているので、符号化が必要とされません。バージョン番号の不在が明確にXML 1.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宣言を含める必要があります。しかしながら、本明細書に記載の正規化方法は、いくつかの変更を加えることなくXMLの将来のバージョンに適用できないかもしれません。 XMLの新しいバージョンの標準化が必要な場合は、おそらくXPathデータモデルからXML宣言の欠如がオンに基づいて、新しいXPathを再発行することで、例えば（その時によって改善することができるように、この仕様では、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 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).

Unicode標準[UNICODE]特定の複数の異なる表現を可能にする（単純な例では、+ U00E7で、「セディーユ付きラテン小文字C」）「の文字を合成済み」。ほとんどのアプリケーションの目的は、異なる文字の配列を含むことができるためと等価であるコンテンツを持つこのように2つのXML文書。 W3Cは、正規表現[CharModel]を準備しています。 C14N-20000119カノニカルXML草案は、この正規化された形式を使用していました。しかし、多くのXML 1.0のプロセッサは、この正規化を実行しないでください。さらに、このような問題を解決しなければならないアプリケーションは、典型的には、（例えば、コーワンの例を参照）文字内容がそうでない可能性があり、処理の失敗を回避するために作成されたときに起動常時文字モデルの正規化を適用します。したがって、キャラクタモデルの正規化は、XMLの標準化の範囲外に移動されました。しかし、XPathデータモデル入力を調製するために使用されるXMLプロセッサは正規化形式C [NFC、NFC-正誤表]を使用する（データ・モデルにより）必要とされるUCSはない任意のエンコーディングからUCS文字ドメインにXMLドキュメントを変換するとき（現在、UCSベースのエンコーディングは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カノニカルXML草案は、文書要素の外側各PIならびに文書要素の終了タグの後の#xA後の#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カノニカルXML草案は、論理的に等価な名前空間宣言を持つ二つの文書も同じ名前空間接頭辞を持っているであろうと、このような名前空間接頭辞を書き換えるための方法を説明しました。目標は、論理等価性をテストする場合、文書内の特定の名前空間接頭辞への依存を排除することでした。しかし、今、名前空間接頭辞は、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はD1で使用される名前空間接頭辞を参照する属性値や要素の内容でXPathを含む文書とします。また、D1での名前空間接頭辞はすべて正規化法によって書き換えされることを前提としています。 D23D D1は、その後、D2内の名前空間接頭辞を変更し、D2とD1は、論理的に等価残るよう名前空間接頭辞にXPath式の参照を変更してみましょう。名前空間の書き換えが属性値と要素のコンテンツ内の名前空間の参照の発生を含まないので、XPathが異なることになるので、D1の標準形は、D2の標準形と等しくありません。名前空間の書き換えが名前空間宣言を正規化がこのように、文書内の特定の名前空間接頭辞への依存をなくす目標は達成されません。

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はD1で使用される名前空間接頭辞を参照する属性値や要素の内容でXPathを含む文書とします。また、D1での名前空間接頭辞はすべて正規化法によって書き換えされることを前提としています。今、D2はD1の正規形とします。（D2がD1の正規形の標準形式であるため）、まだ前述のXPathがD1で動作し、D2に動作しないので、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.

ここで我々が意図的にこのような制限を導入することを避けるために機会を持っているのに対し、これと同様の引数は制限内のいずれかの場合に基づいてXML正則化法に対する平準化できることに注意してください、問題が簡単な場合には、固定することができません。

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関連の勧告、草案、および将来の作品からアプリケーションルールなどのルールに基づいて、論理等価性をテストするために、どのような場合に必要になることは非常に可能性があります。

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正規の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正則化法は、宣言を省略します。それは親要素を持たないため、ルート文書要素は、特別に処理されます。その中のすべての名前空間宣言は、空のデフォルトの名前空間の宣言が自動的に省略されている以外、保持されます。

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:

単に各要素の全体の名前空間コンテキストをレンダリングする方法に比べて、実装は、処理時間とメモリ使用に一定の係数以上に妨げていません。利点としては、

       * 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.

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データモデルは、ノードが存在しない場合と、しない空の値を有するデフォルトの名前空間ノードの存在と、空のデフォルトの名前空間を表します。 <E2ののxmlns =「」> <E3 /> </ E2>：したがって、次の例の要素E3は、名前空間で修飾されていないという事実に関して、我々は<のE1のxmlns =「B」>との違いを見分けることはできません</ E1>対<E1とのxmlns = "B"> <E2> <E3のxmlns = "" /> </ E2> </ E1>。私たちが知っているすべては、E3が入力に名前空間で修飾されなかったということですので、E2が省略された場合は、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名前仕様の意図に近いしかし、名前空間URIは、主キーとして選択しました。ソートの効果は、一緒にグループに同じ名前空間にあるすべての属性です。

Security Considerations

セキュリティの考慮事項

Security issues are discussed in section 1.3.

セキュリティ問題はセクション1.3で説明されています。

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.コーワン。 1月19日、2000年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]ワーキングドラフト。編。マーティン・J.ダースト、フランソワYergeau、ミーシャ・ウルフ、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.

[インフォセット] XML情報セット、W3Cワーキングドラフト。ジョン・コーワン、リチャード・トービン。 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.

[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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勧告で名前空間。編。ティム・ブレイ、デイブ・ホランダー、そしてアンドリュー素人。 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、Unicode正規化フォーム。 M.デイヴィス、M.ダースト。リビジョン18：1999年11月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/ 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.

[UNICODE] Unicode規格、バージョン3.0。ユニコードコンソーシアム。 ISBN 0-201-61633-5。 http://www.unicode.org/unicode/standard/バージョン/ Unicode3.0.html。

[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.

[UTF-16]ホフマン、P.及びF. Yergeau、 "UTF-16、ISO 10646の符号化"、RFC 2781、2000年2月。

[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。

[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[URI]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。

[XBase] XML Base ed. Jonathan Marsh. 07 June 2000. http://www.w3.org/TR/xmlbase/.

[XBaseと] XMLベース編。ジョナサン・マーシュ。 6月7日、2000年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（第二版）、W3C勧告= 20。編。ティム・ブレイ、ジーン・パオリ、C. M. Sperberg-マックイーンとイブMALER。 10月6日2000年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-署名構文と処理"、RFC 3075、2000年7月。

[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.

[XML総会決定]名前空間宣言、W3Cドキュメントの相対URI参照にW3C XML総会決定は。 9月11日2000年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パス言語（XPath）バージョン1.0、W3C勧告。編。 James Clark氏とスティーブン・デローズ。 1999年11月16日http://www.w3.org/TR/1999/REC-xpath-19991116。

Author's Address

著者のアドレス

John Boyer PureEdge Solutions Inc.

ジョン・ボワイエPureEdgeソリューションズ株式会社

Phone: 1-888-517-2675 EMail: jboyer@PureEdge.com

電話：1-888-517-2675 Eメール：jboyer@PureEdge.com

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

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（2001）。全著作権所有。

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.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

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機能のための基金は現在、インターネット協会によって提供されます。