RFC 3076 - Canonical XML Version 1.0 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3076
タイトル : RFC 3076 - 標準XMLバージョン1.0
翻訳編集 : 自動生成

[要約] RFC 3076は、XML文書の正規化と一貫性を確保するための仕様です。目的は、XML文書の互換性とセキュリティを向上させることです。

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

Canonical XML Version 1.0

標準XMLバージョン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.

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

著作権表示

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 1.0およびXMLの名前空間で許可されている構文の変更に基づいて物理表現が異なります。この仕様では、許容される変更を説明するXMLドキュメントの物理的表現、標準形式を生成する方法について説明します。いくつかの異常なケースに関する制限を除き、2つのドキュメントに同じ標準形式がある場合、2つのドキュメントは指定されたアプリケーションコンテキスト内で論理的に同等です。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つのドキュメントが同一であるかどうか、またはアプリケーションがドキュメントを変更していないかどうかを判断する方法を確立することです。

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

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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

* ドキュメントは、検証済みのプロセッサ *文字と解析されたエンティティ参照が置き換えられるかのように、 *属性値が正規化される前に、入力で＃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 Canonicalizationメソッドを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 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 1.0または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ドキュメントが同一である場合にのみ2つのXMLドキュメントが同等であるような方法を確立することはこの作業の目標ではありません。。このような方法は、重要でない空白や同等のデータを支配するものなどのアプリケーション固有のルール（例：<color> black </color>対<color> RGB（0,0,0）</color>）。他の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は標準的な形式で動作しません。）。これらの問題は両方とも、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.

2番目のケースでは、外部の未分類のエンティティ参照の喪失とアプリケーションに結合する表記は、このメカニズムを介して未分類のデータを組み込んだ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.

3番目のケースでは、属性タイプの損失は、タイプに応じて異なる方法で標準形式に影響を与える可能性があります。タイプ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.

これらの制限は深刻ではありませんが、たとえば、W3Cで現在開発中のXML情報セット[InfoSet]に基づいてXPATHの新しいバージョンが作成された場合、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.

XPath 1.0推奨[XPath]で定義されているデータモデルは、入力XMLドキュメントまたはドキュメントサブセットを表すために使用されます。実装は、XPathの実装に基づいている必要はありません。XML Canonicalizationは、ノードセットの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ドキュメントを含むOctetストリームのいずれかです。実装は、Octetストリーム入力をサポートする必要があり、ノードセット入力を介してドキュメントサブセット機能もサポートする必要があります。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 Canonicalizationメソッドへの入力の2番目のパラメーターは、XML Canonicalizationメソッドによってコメントを標準形式の出力に含めるべきかどうかを示すブールフラグです。Canonicalフォームに、入力ノードセットのコメントノードに対応するコメントが含まれている場合、結果はコメント付きのCanonical 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.属性値を正規化する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プロセッサの動作に従って、属性値の正規化とエンティティ参照解決を実行する必要があります。同様に、デフォルト属性のノード（ATTLISTで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をサポートし、UCS文字ドメインに変換するXMLプロセッサを使用する必要があります。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.

ルートドキュメント要素内のすべてのホワイトスペースは、保存する必要があります（Line Delimiter Normizationによって削除された＃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.

注：要素には、スタートタグに表示される非ネームズスペース属性宣言を表す属性ノードと、デフォルトの属性を表すノードがあります。

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の説明を参照）。XPathデータモデルでは、各要素と属性には、アプリケーションの裁量で、元のドキュメントに表示されるQNameにすることができる関数名（）によって返される名前があります。XML Canonicalizationでは、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注：この仕様は、相対名のurisを次のように非難するという最近のXML全体の決定をサポートしています。XML標準化の実装は、相対名のurisを含むドキュメントの操作障害を報告する必要があります。XML Canonicalizationは、相対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 Canonicalizationメソッドは、文字モデルの正規化を実行しません（セクション4の説明を参照）。ただし、XMLドキュメントをUCSベースではないエンコーディングからUCS文字ドメインに変換する場合、XPATHデータモデル入力の準備に使用されるXMLプロセッサは、XMLドキュメントをUCS文字ドメインに変換するときに正規化フォームC [NFC、NFC-Corrigendum]を使用するために必要です（現在、UCS - ベースのエンコーディングには、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処理を実行してOctetストリームからノードセットに変換する必要があります。上記で説明し、次の最初の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に初期化されたコンテキスト位置。 *コンテキストサイズ、初期化。*可変バインディングの空のセット。*名前空間宣言の空のセット。

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

この表の式は、XMLドキュメントのすべてのノードを含むノードセットを生成します（コメントパラメーター値がfalseの場合のコメントを除く）。

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表現の最初の文字が拡張後にドキュメントの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).

* 要素の名前空間と属性ノードには、要素よりも大きいが、要素の子ノードよりも小さいドキュメント順序位置があります。*名前空間ノードは、属性ノードよりもドキュメントの注文位置が少ない。*要素の名前空間ノードは、ローカル名で辞書化されています（デフォルトの名前空間ノードが存在する場合、ローカル名がなく、したがって辞書的に最も少ない）。*要素の属性ノードは、名前空間URIがプライマリキーとして、セカンダリキーとしてローカル名として辞書化されています（空の名前空間URIは辞書的に最も少ない）。

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ノードセットは、昇順のドキュメント順序でノードセットの各ノードの代表的なUCS文字を生成し、UTF-8で結果をエンコードすることにより、標準形式のオクテットストリームに変換されます（リーディングバイトオーダーマークなしで結果をエンコードします）。ノードは複数回処理されていません。要素ノード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.

* ルートノード - ルートノードは、トップレベルのドキュメント要素の親です。ドキュメントの順序でノードセットにある各子ノードを処理した結果。ルートノードは、バイト順序マーク、XML宣言、ドキュメントタイプの宣言内からのものではありません。

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

* 要素ノード - 要素がノードセットにない場合、結果は名前空間軸を処理し、属性軸を処理し、次にノードセットにある要素の子ノードを処理することによって取得されます（ドキュメント順序で）。要素がノードセットにある場合、結果はオープン角度ブラケット（<）、要素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:

* o名前空間軸 - 軸順にノードセットの名前空間ノードのみを含むリストLを検討してください（上昇）。Lの処理を開始するには、最初のノードがデフォルトの名前空間ノード（名前空間URIとローカル名のないノード）ではない場合、次の条件が満たされている場合にのみ、XMLNS = ""の場合のスペースを生成します。

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

+ 軸を所有する要素Eはノードセットにあります。ノードセットのEの最寄りの祖先要素は、ノードセットにデフォルトの名前空間ノードを持っています（デフォルトの名前空間ノードは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の処理を完了するには、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 属性軸 - 辞書編集の順序（上昇）で、要素の属性軸とノードセットにある各ノードを処理します。

* 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と同じローカル名と値を持つ名前空間ノードがあります。ノードn属性ノードと同じ方法で、存在する場合はローカル名xmlnsをデフォルトの名前空間ノードに割り当てることを除きます（xpathでは、デフォルトの名前空間ノードには空のURIとローカル名があります）。

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

* 属性ノード - スペース、ノードのQName、等しいサイン、オープンクォートマーク（二重引用符）、変更された文字列値、および緊密な引用マーク（二重引用符）。ノードの文字列値は、すべてのアンパサンド（＆）を＆amp;、すべてのオープンアングルブラケット（<）で置き換えることにより変更されます。xa、および#xd、文字参照。文字参照は、先頭のゼロがない大文字の16進数で記述されています（たとえば、＃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 .

* テキストノード - すべてのアンパサンドが＆amp;に置き換えられることを除く文字列値（すべてのオープン角度ブラケット（<）が＆lt;に置き換えられます。＆＃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）ノード - オープニングPIシンボル（<？）、NODEのPIターゲット名、空でない場合は先行スペースと文字列値、および閉じたPIシンボル（？>）。文字列値が空の場合、先行スペースは追加されません。また、トレーリング#XAは、ドキュメント要素よりも低いドキュメント注文で、ルートノードのPI子供のPIシンボルの後にレンダリングされ、ルートノードのPI子供のPIシンボルのオープニングPIシンボルの前にリーディング#XAがレンダリングされます。ドキュメント要素よりも大きなドキュメント注文。

* 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を生成する場合は何もありません。コメント付きの正規の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.

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

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の属性軸を処理する方法が強化されています。Eの祖先軸に沿ったすべての要素ノードは、XML：LangおよびXML：Space（ノードセットにあるかどうかにかかわらず）など、XMLネームスペースの属性の最も近い発生について調べられます。この属性のリストから、Eの属性軸にあるものを削除します（ノードセットにあるかどうかにかかわらず）。次に、この属性リストを、ノードセットにあるEの属性軸のノードと辞書的にマージします。属性軸にアクセスした結果は、このマージされた属性リストの属性ノードを処理することにより計算されます。

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ドキュメントまたは外部一般的な解析エンティティである標準形式を生成するように設計されます。完全なドキュメントであろうとドキュメントのサブセットからであろうと、標準形式がよく形成されている場合、その後の標準化形式へのその後のアプリケーションは、変更されません。

3. Examples of XML Canonicalization

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

このセクションの例は、主にドキュメントタイプの宣言を使用して、すべての属性をすべてのすべての属性を宣言することなく、さまざまなタイプのデフォルトの属性と属性（IDや列挙など）を宣言するために主に、非検証プロセッサを想定しています。ドキュメント内の要素。同様に、1つの例には、妥当性の制約に意図的に違反する要素が含まれています（まだよく形成されているため）。

3.1 PIs, Comments, and Outside of Document Element

3.1 PI、コメント、およびドキュメント要素の外

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

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

   <!DOCTYPE doc SYSTEM "doc.dtd">

   <doc>Hello, world!<!-- Comment 1 --></doc>

<?pi-without-data ?>

<？pi-without-data？>

   <!-- Comment 2 -->

   <!-- Comment 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 '>')

* XML宣言の喪失 * DTDの損失 *ドキュメント要素の外側の空白の正規化（両方の標準形式の最初の文字は '<';単一行がドキュメント要素の外で個別のPIとコメントを破ります）PIデータ内の空白の保持 *コメント削除された標準形式からのコメント削除、ドキュメント要素の外部のコメントのデリミターを含む（両方の標準形式の最後の文字は '>'）

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>

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>

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の前にa：attrの前にあります。主キーは名前空間uriではなく名前空間プレフィックスではなく、attr2はb：attrの先行します。

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 (&, <, ", , 
, 	) * Encoding of special characters as character references in text (&, <, >, )

* 文字参照の交換 *引用符に設定された属性値デリミター（二重引用符）#xa;、＆＃x9;） *テキストの文字参照としての特殊文字のエンコード（＆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以外のWhitespace文字参照。属性値正規化[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.

注：標準形式では、要素normの属性属性の値の値は、スペース、単一の引用、次に最初の文字参照の4つのスペースから始まります。

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

注：2番目の計算要素の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>

   <!-- Let world.txt contain "world" (excluding the quotes) -->

   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

* 内部解析エンティティリファレンス交換 *外部解析エンティティリファレンス交換（ホワイトスペースの外部要素とPIを含む） *外部非散布されたエンティティリファレンス

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ではなく、copyrightシンボル（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

* 省略された親要素からの空のデフォルトの名前空間伝播 *ドキュメントサブセットのXMLネームスペースの属性の伝播 *子孫の省略された名前空間宣言の永続性

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

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 InfosetではなくXMLデータモデルの観点からXML標準化を定義するようになりましたが、このドキュメントで説明されている標準形式は、ほとんどの点で2000年1月の標準的なXMLドラフト[C14N-20019]に記載されている標準形式と非常に類似しています。ただし、いくつかの違いが存在し、多くのサブセクションが変更について議論しています。

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の新しいバージョンの標準化が必要な場合、この仕様は、XML宣言を含めるように更新される可能性があります。おそらく、XPATHデータモデルからのXML宣言が存在しないことをその時までに改善することができます（例えば、新しいXPathを再発行することにより、InfoSetデータモデル）。

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 Canonical XMLドラフトは、この正規化されたフォームを使用しました。ただし、多くのXML 1.0プロセッサはこの正規化を実行しません。さらに、この問題を解決しなければならないアプリケーションは、通常、キャラクターモデルの正規化を常に強制します。そうでなければ生じる可能性のある処理障害を回避するために、文字コンテンツが作成されたときに起動します（たとえば、Cowanの例を参照）。したがって、XML Canonicalizationのために、文字モデルの正規化が範囲外に移動されました。ただし、XMLドキュメントをUCSではないエンコーディングからUCS文字ドメインに変換するときに、XPATHデータモデル入力を準備するために使用されるXMLプロセッサが（データモデルによって）正規化フォームC [NFC、NFC-Corrigendum]を使用するために必要です。 - ベース（現在、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 Canonical 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 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を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の標準形式とします。明らかに、D1とD2の標準的な形態は同等です（D2はD1の標準形式の標準形式であるため）が、D1とD2は前述のXPathが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 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関連の推奨事項、ワーキングドラフト、および将来の作業からのルールに基づいて論理的な等価性をテストするために、いずれにせよ必要である可能性が非常に高いです。

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

各要素の名前空間コンテキスト全体を単にレンダリングする方法と比較して、実装は、処理時間とメモリ使用の一定の要因以上のものによって妨げられません。利点は次のとおりです。

* 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>。私たちが知っているのは、E3が入力で名前空間の資格がないということです。したがって、E3がE1のデフォルトの名前空間資格を取得しないように、E2が省略されている場合、出力に関するこの情報を保存します。

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-20019]標準XMLバージョン1.0、W3Cワーキングドラフト。T.ブレイ、J。クラーク、J。タウバー、J。コーワン。2000年1月19日。http：//www.w3.org/tr/2000/wd-xml-c14n-20019.html。

[CharModel] Working Draft. eds. Martin J. Durst, Francois Yergeau, Misha Wolf, Asmus Freytag, Tex Texin. http://www.w3.org/TR/charmod/.

[Charmodel]ワーキングドラフト。eds。マーティン・J・ダースト、フランソワ・エルゴー、ミシャ・ウルフ、アスマス・フレイタグ、テックス・テキシン。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.

[Cowan]キャラクターモデルの正規化の有害な効果の例、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.

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

[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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の推奨。eds。ティム・ブレイ、デイブ・ホランダー、アンドリュー・レイマン。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：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-Corrigendum] NFC-Corrigendum。ユニコードコンソーシアム。http://www.unicode.org/unicode/uni2errata/ remarization_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/ versions/unicode3.0.html。

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

[UTF-16] Hoffman、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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、RFC 2396、1998年8月。

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

[XBase] XMLベースed。ジョナサン・マーシュ。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（第2版）、W3C = 20の推奨。eds。ティム・ブレイ、ジャン・パオリ、C。M。スペルバーグ・マックーン、イブ・マラー。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] EastLake、D.、Reagle、J。およびD. Solo、「XML-Signature Syntax and Processing」、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 XML名前空間宣言、W3Cドキュメントの相対的なURI参照に関する全体的な決定。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パス言語（XPath）バージョン1.0、、W3C推奨。eds。ジェームズ・クラークとスティーブン・デロース。1999年11月16日。http：//www.w3.org/tr/1999/rec-xpath-19991116。

Author's Address

著者の連絡先

John Boyer PureEdge Solutions Inc.

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

電話：1-888-517-2675メール：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

* ダグ・バンティング、アリバ *ジョン・コーワン、ロイター *マーティン・J・ダースト、W3C *ドナルド・イーストレイク・3rd、モトローラ・メルリン・ヒューズ、ボルチモア *グレゴール・カーリンガー、IAIK TU GRAZ *スーザン・レッシュ、W3C *ジョナサン・マーシュ、マイクロソフト *ジョセフ・レーグル、W3C *Petteri Stenius、done360 * Kent Tamura、IBM

Full Copyright Statement

完全な著作権声明

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