draft-ietf-xmldsig-canonical-01.txt   rfc3076.txt 
INTERNET-DRAFT Canonical XML
Expires July 2001 January 2001
Canonical XML
Version 1.0
<draft-ietf-xmldsig-canonical-01.txt>
John Boyer
Status of This Document
This document is a product of the joint IETF/W3C XMLDSIG working
group. It is intended to become an Informational RFC version of the
W3C Proposed Recommendation of the same name
<http://www.w3.org/TR/2000/PR-xml-c14n-20010119>. Distribution of
this document is unlimited. Comments should be sent to the XMLDSIG WG
mailing list <w3c-ietf-xmldsig@w3.org> or to the author.
This document is an Internet-Draft and is in full conformance with Network Working Group J. Boyer
all provisions of Section 10 of RFC 2026. Internet-Drafts are Request for Comments: 3076 PureEdge Solutions Inc.
working documents of the Internet Engineering Task Force (IETF), its Category: Informational March 2001
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Canonical XML Version 1.0
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of this Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All Copyright (C) The Internet Society (2001). All Rights Reserved.
Rights Reserved. W3C liability, trademark, document use and software
licensing rules apply.
Abstract Abstract
Any XML document is part of a set of XML documents that are logically Any XML (Extensible Markup Language) document is part of a set of XML
equivalent within an application context, but which vary in physical documents that are logically equivalent within an application
representation based on syntactic changes permitted by XML 1.0 [XML] context, but which vary in physical representation based on syntactic
and Namespaces in XML [Names]. This specification describes a method changes permitted by XML 1.0 and Namespaces in XML. This
for generating a physical representation, the canonical form, of an specification describes a method for generating a physical
XML document that accounts for the permissible changes. Except for representation, the canonical form, of an XML document that accounts
limitations regarding a few unusual cases, if two documents have the for the permissible changes. Except for limitations regarding a few
same canonical form, then the two documents are logically equivalent unusual cases, if two documents have the same canonical form, then
within the given application context. Note that two documents may the two documents are logically equivalent within the given
have differing canonical forms yet still be equivalent in a given application context. Note that two documents may have differing
context based on application-specific equivalence rules for which no canonical forms yet still be equivalent in a given context based on
generalized XML specification could account. application-specific equivalence rules for which no generalized XML
specification could account.
Acknowledgements
The following people provided valuable feedback that improved the
quality of this specification:
* Doug Bunting, Ariba
* John Cowan, Reuters
* Martin J. Durst, W3C
* Merlin Hughes, Baltimore
* Gregor Karlinger, IAIK TU Graz
* Susan Lesch, W3C
* Jonathan Marsh, Microsoft
* Joseph Reagle, W3C
* Petteri Stenius, Done360
* Kent TAMURA, IBM
Table of Contents Table of Contents
Status of This Document....................................1 1. Introduction............................................... 2
Copyright Notice...........................................1 1.1 Terminology............................................... 3
1.2 Applications.............................................. 4
Abstract...................................................2 1.3 Limitations............................................... 4
Acknowledgements...........................................2 2. XML Canonicalization....................................... 6
2.1 Data Model................................................ 6
Table of Contents..........................................3 2.2 Document Order............................................ 10
2.3 Processing Model.......................................... 10
1. Introduction............................................4 2.4 Document Subsets.......................................... 13
1.1 Terminology............................................4 3. Examples of XML Canonicalization........................... 14
1.2 Applications...........................................5 3.1 PIs, Comments, and Outside of Document Element............ 14
1.3 Limitations............................................6 3.2 Whitespace in Document Content............................ 15
2. XML Canonicalization....................................7 3.3 Start and End Tags........................................ 16
2.1 Data Model.............................................7 3.4 Character Modifications and Character References.......... 17
2.2 Document Order........................................11 3.5 Entity References......................................... 19
2.3 Processing Model......................................11 3.6 UTF-8 Encoding............................................ 19
2.4 Document Subsets......................................14 3.7 Document Subsets.......................................... 20
3 Examples of XML Canonicalization........................15 4. Resolutions................................................ 21
3.1 PIs, Comments, and Outside of Document Element........15 4.1 No XML Declaration........................................ 21
3.2 Whitespace in Document Content........................16 4.2 No Character Model Normalization.......................... 21
3.3 Start and End Tags....................................17 4.3 Handling of Whitespace Outside Document Element........... 22
3.4 Character Modifications and Character References......19 4.4 No Namespace Prefix Rewriting............................. 22
3.5 Entity References.....................................20 4.5 Order of Namespace Declarations and Attributes............ 23
3.6 UTF-8 Encoding........................................21 4.6 Superfluous Namespace Declarations........................ 23
3.7 Document Subsets......................................21 4.7 Propagation of Default Namespace Declaration in Document
4 Resolutions.............................................22 Subsets................................................... 24
4.1 No XML Declaration....................................22 4.8 Sorting Attributes by Namespace URI....................... 24
4.2 No Character Model Normalization......................23 Security Considerations....................................... 24
4.3 Handling of Whitespace Outside Document Element.......23 References.................................................... 25
4.4 No Namespace Prefix Rewriting.........................23 Author's Address.............................................. 26
4.5 Order of Namespace Declarations and Attributes........24 Acknowledgements.............................................. 27
4.6 Superfluous Namespace Declarations....................25 Full Copyright Statement...................................... 28
4.7 Propagation of Default Namespace Declaration in Document
Subsets...............................................25
4.8 Sorting Attributes by Namespace URI...................26
References................................................26
Author's Address..........................................28
Expiration and File Name..................................28
1. Introduction 1. Introduction
The XML 1.0 Recommendation [XML] specifies the syntax of a class of The XML 1.0 Recommendation [XML] specifies the syntax of a class of
resources called XML documents. The Namespaces in XML Recommendation resources called XML documents. The Namespaces in XML Recommendation
[Names] specifies additional syntax and semantics for XML documents. [Names] specifies additional syntax and semantics for XML documents.
It is possible for XML documents which are equivalent for the It is possible for XML documents which are equivalent for the
purposes of many applications to differ in physical representation. purposes of many applications to differ in physical representation.
For example, they may differ in their entity structure, attribute For example, they may differ in their entity structure, attribute
ordering, and character encoding. It is the goal of this ordering, and character encoding. It is the goal of this
specification to establish a method for determining whether two specification to establish a method for determining whether two
documents are identical, or whether an application has not changed a documents are identical, or whether an application has not changed a
document, except for transformations permitted by XML 1.0 and document, except for transformations permitted by XML 1.0 and
Namespaces. Namespaces.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [Keywords]. document are to be interpreted as described in RFC 2119 [Keywords].
See [Names] for the definition of QName. See [Names] for the definition of QName.
A document subset is a portion of an XML document indicated by a 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. node-set that may not include all of the nodes in the document.
The canonical form of an XML document is physical representation of The canonical form of an XML document is physical representation of
the document produced by the method described in this specification. the document produced by the method described in this specification.
The changes are summarized in the following list: The changes are summarized in the following list:
* The document is encoded in UTF-8 * The document is encoded in UTF-8
* Line breaks normalized to #xA on input, before parsing * Line breaks normalized to #xA on input, before parsing
* Attribute values are normalized, as if by a validating processor * Attribute values are normalized, as if by a validating
* Character and parsed entity references are replaced processor
* CDATA sections are replaced with their character content * Character and parsed entity references are replaced
* The XML declaration and document type declaration (DTD) are * CDATA sections are replaced with their character content
removed * The XML declaration and document type declaration (DTD) are
* Empty elements are converted to start-end tag pairs removed
* Whitespace outside of the document element and within start and * Empty elements are converted to start-end tag pairs
end tags is normalized * Whitespace outside of the document element and within start and
* All whitespace in character content is retained (excluding end tags is normalized
characters removed during line feed normalization) * All whitespace in character content is retained (excluding
* Attribute value delimiters are set to quotation marks (double characters removed during line feed normalization)
quotes) * Attribute value delimiters are set to quotation marks (double
* Special characters in attribute values and character content are quotes)
replaced by character references * Special characters in attribute values and character content
* Superfluous namespace declarations are removed from each element are replaced by character references
* Default attributes are added to each element * Superfluous namespace declarations are removed from each
* Lexicographic order is imposed on the namespace declarations and element
attributes of 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 The term canonical XML refers to XML that is in canonical form. The
XML canonicalization method is the algorithm defined by this XML canonicalization method is the algorithm defined by this
specification that generates the canonical form of a given XML specification that generates the canonical form of a given XML
document or document subset. The term XML canonicalization refers to document or document subset. The term XML canonicalization refers to
the process of applying the XML canonicalization method to an XML the process of applying the XML canonicalization method to an XML
document or document subset. document or document subset.
The XPath 1.0 Recommendation [XPath] defines the term node-set and The XPath 1.0 Recommendation [XPath] defines the term node-set and
specifies a data model for representing an input XML document as a specifies a data model for representing an input XML document as a
set of nodes of various types (element, attribute, namespace, text, set of nodes of various types (element, attribute, namespace, text,
comment, processing instruction, and root). The nodes are included in comment, processing instruction, and root). The nodes are included
or excluded from a node-set based on the evaluation of an expression. in or excluded from a node-set based on the evaluation of an
Within this specification, a node-set is used to directly indicate expression. Within this specification, a node-set is used to
whether or not each node should be rendered in the canonical form (in directly indicate whether or not each node should be rendered in the
this sense, it is used as a formal mathematical set). A node that is canonical form (in this sense, it is used as a formal mathematical
excluded from the set is not rendered in the canonical form being set). A node that is excluded from the set is not rendered in the
generated, even if its parent node is included in the node-set. canonical form being generated, even if its parent node is included
However, an omitted node may still impact the rendering of its in the node-set. However, an omitted node may still impact the
descendants (e.g. by augmenting the namespace context of the rendering of its descendants (e.g., by augmenting the namespace
descendants). context of the descendants).
1.2 Applications 1.2 Applications
Since the XML 1.0 Recommendation [XML] and the Namespaces in XML Since the XML 1.0 Recommendation [XML] and the Namespaces in XML
Recommendation [Names] define multiple syntactic methods for Recommendation [Names] define multiple syntactic methods for
expressing the same information, XML applications tend to take expressing the same information, XML applications tend to take
liberties with changes that have no impact on the information content liberties with changes that have no impact on the information content
of the document. XML canonicalization is designed to be useful to of the document. XML canonicalization is designed to be useful to
applications that require the ability to test whether the information applications that require the ability to test whether the information
content of a document or document subset has been changed. This is content of a document or document subset has been changed. This is
done by comparing the canonical form of the original document before done by comparing the canonical form of the original document before
application processing with the canonical form of the document result application processing with the canonical form of the document result
of the application processing. of the application processing.
For example, a digital signature over the canonical form of an XML For example, a digital signature over the canonical form of an XML
document or document subset would allow the signature digest document or document subset would allow the signature digest
calculations to be oblivious to changes in the original document's calculations to be oblivious to changes in the original document's
physical representation, provided that the changes are defined to be physical representation, provided that the changes are defined to be
logically equivalent by the XML 1.0 or Namespaces in XML. During logically equivalent by the XML 1.0 or Namespaces in XML. During
signature generation, the digest is computed over the canonical form signature generation, the digest is computed over the canonical form
of the document. The document is then transferred to the relying of the document. The document is then transferred to the relying
party, which validates the signature by reading the document and party, which validates the signature by reading the document and
computing a digest of the canonical form of the received document. computing a digest of the canonical form of the received document.
The equivalence of the digests computed by the signing and relying The equivalence of the digests computed by the signing and relying
parties (and hence the equivalence of the canonical forms over which parties (and hence the equivalence of the canonical forms over which
they were computed) ensures that the information content of the they were computed) ensures that the information content of the
document has not been altered since it was signed. document has not been altered since it was signed.
1.3 Limitations 1.3 Limitations
Two XML documents may have differing information content that is Two XML documents may have differing information content that is
nonetheless logically equivalent within a given application context. nonetheless logically equivalent within a given application context.
Although two XML documents are equivalent (aside from limitations Although two XML documents are equivalent (aside from limitations
given in this section) if their canonical forms are identical, it is 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 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 documents are equivalent if and only if their canonical forms are
identical. Such a method is unachievable, in part due to identical. Such a method is unachievable, in part due to
application-specific rules such as those governing unimportant application-specific rules such as those governing unimportant
whitespace and equivalent data (e.g. <color>black</color> versus whitespace and equivalent data (e.g., <color>black</color> versus
<color>rgb(0,0,0)</color>). There are also equivalencies established <color>rgb(0,0,0)</color>). There are also equivalencies established
by other W3C Recommendations and Working Drafts. Accounting for by other W3C Recommendations and Working Drafts. Accounting for
these additional equivalence rules is beyond the scope of this work. these additional equivalence rules is beyond the scope of this work.
They can be applied by the application or become the subject of They can be applied by the application or become the subject of
future specifications. future specifications.
The canonical form of an XML document may not be completely The canonical form of an XML document may not be completely
operational within the application context, though the circumstances operational within the application context, though the circumstances
under which this occurs are unusual. This problem may be of concern under which this occurs are unusual. This problem may be of concern
in certain applications since the canonical form of a document and the in certain applications since the canonical form of a document and
canonical form of the canonical form of the document are equivalent. the canonical form of the canonical form of the document are
For example, in a digital signature application, the canonical form equivalent. For example, in a digital signature application, the
can be substituted for the original document without changing the canonical form can be substituted for the original document without
digest calculation. However, the security risk only occurs in the changing the digest calculation. However, the security risk only
unusual circumstances described below, which can all be resolved or occurs in the unusual circumstances described below, which can all be
at least detected prior to digital signature generation. resolved or at least detected prior to digital signature generation.
The difficulties arise due to the loss of the following information The difficulties arise due to the loss of the following information
not available in the data model: not available in the data model:
1. base URI, especially in content derived from the replacement 1. base URI, especially in content derived from the replacement
text of external general parsed entity references text of external general parsed entity references
2. notations and external unparsed entity references 2. notations and external unparsed entity references
3. attribute types in the document type declaration 3. attribute types in the document type declaration
In the first case, note that a document containing a relative URI In the first case, note that a document containing a relative URI
[URI] is only operational when accessed from a specific URI that [URI] is only operational when accessed from a specific URI that
provides the proper base URI. In addition, if the document contains provides the proper base URI. In addition, if the document contains
external general parsed entity references to content containing external general parsed entity references to content containing
relative URIs, then the relative URIs will not be operational in the relative URIs, then the relative URIs will not be operational in the
canonical form, which replaces the entity reference with internal canonical form, which replaces the entity reference with internal
content (thereby implicitly changing the default base URI of that content (thereby implicitly changing the default base URI of that
content). Both of these problems can typically be solved by adding content). Both of these problems can typically be solved by adding
support for the xml:base attribute [XBase] to the application, then support for the xml:base attribute [XBase] to the application, then
adding appropriate xml:base attributes to document element and all adding appropriate xml:base attributes to document element and all
top-level elements in external entities. In addition, applications top-level elements in external entities. In addition, applications
often have an opportunity to resolve relative URIs prior to the need often have an opportunity to resolve relative URIs prior to the need
for a canonical form. For example, in a digital signature for a canonical form. For example, in a digital signature
application, a document is often retrieved and processed prior to application, a document is often retrieved and processed prior to
signature generation. The processing SHOULD create a new document in signature generation. The processing SHOULD create a new document in
which relative URIs have been converted to absolute URIs, thereby which relative URIs have been converted to absolute URIs, thereby
mitigating any security risk for the new document. mitigating any security risk for the new document.
In the second case, the loss of external unparsed entity references In the second case, the loss of external unparsed entity references
and the notations that bind them to applications means that canonical and the notations that bind them to applications means that canonical
forms cannot properly distinguish among XML documents that forms cannot properly distinguish among XML documents that
incorporate unparsed data via this mechanism. This is an unusual case incorporate unparsed data via this mechanism. This is an unusual
precisely because most XML processors currently discard the document case precisely because most XML processors currently discard the
type declaration, which discards the notation, the entity's binding document type declaration, which discards the notation, the entity's
to a URI, and the attribute type that binds the attribute value to an binding to a URI, and the attribute type that binds the attribute
entity name. For documents that must be subjected to more than one value to an entity name. For documents that must be subjected to
XML processor, the XML design typically indicates a reference to more than one XML processor, the XML design typically indicates a
unparsed data using a URI in the attribute value. reference to unparsed data using a URI in the attribute value.
In the third case, the loss of attribute types can affect the In the third case, the loss of attribute types can affect the
canonical form in different ways depending on the type. Attributes of canonical form in different ways depending on the type. Attributes
type ID cease to be ID attributes. Hence, any XPath expressions that of type ID cease to be ID attributes. Hence, any XPath expressions
refer to the canonical form using the id() function cease to operate. that refer to the canonical form using the id() function cease to
The attribute types ENTITY and ENTITIES are not part of this case; operate. The attribute types ENTITY and ENTITIES are not part of
they are covered in the second case above. Attributes of enumerated this case; they are covered in the second case above. Attributes of
type and of type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS, and NOTATION enumerated type and of type ID, IDREF, IDREFS, NMTOKEN, NMTOKENS, and
fail to be appropriately constrained during future attempts to change NOTATION fail to be appropriately constrained during future attempts
the attribute value if the canonical form replaces the original to change the attribute value if the canonical form replaces the
document during application processing. Applications can avoid the original document during application processing. Applications can
difficulties of this case by ensuring that an appropriate document avoid the difficulties of this case by ensuring that an appropriate
type declaration is prepended prior to using the canonical form in document type declaration is prepended prior to using the canonical
further XML processing. This is likely to be an easy task since form in further XML processing. This is likely to be an easy task
attribute lists are usually acquired from a standard external DTD since attribute lists are usually acquired from a standard external
subset, and any entity and notation declarations not also in the DTD subset, and any entity and notation declarations not also in the
external DTD subset are typically constructed from application external DTD subset are typically constructed from application
configuration information and added to the internal DTD subset. configuration information and added to the internal DTD subset.
While these limitations are not severe, it would be possible to While these limitations are not severe, it would be possible to
resolve them in a future version of XML canonicalization if, for resolve them in a future version of XML canonicalization if, for
example, a new version of XPath were created based on the XML example, a new version of XPath were created based on the XML
Information Set [Infoset] currently under development at the W3C. Information Set [Infoset] currently under development at the W3C.
2. XML Canonicalization 2. XML Canonicalization
2.1 Data Model 2.1 Data Model
The data model defined in the XPath 1.0 Recommendation [XPath] is The data model defined in the XPath 1.0 Recommendation [XPath] is
used to represent the input XML document or document subset. used to represent the input XML document or document subset.
Implementations SHOULD but need not be based on an XPath Implementations SHOULD but need not be based on an XPath
implementation. XML canonicalization is defined in terms of the XPath implementation. XML canonicalization is defined in terms of the
definition of a node-set, and implementations MUST produce equivalent XPath definition of a node-set, and implementations MUST produce
results. equivalent results.
The first parameter of input to the XML canonicalization method is The first parameter of input to the XML canonicalization method is
either an XPath node-set or an octet stream containing a well-formed either an XPath node-set or an octet stream containing a well-formed
XML document. Implementations MUST support the octet stream input XML document. Implementations MUST support the octet stream input
and SHOULD also support the document subset feature via node-set and SHOULD also support the document subset feature via node-set
input. For the purpose of describing canonicalization in terms of an input. For the purpose of describing canonicalization in terms of an
XPath node-set, this section describes how an octet stream is XPath node-set, this section describes how an octet stream is
converted to an XPath node-set. converted to an XPath node-set.
The second parameter of input to the XML canonicalization method is a The second parameter of input to the XML canonicalization method is a
boolean flag indicating whether or not comments should be included in boolean flag indicating whether or not comments should be included in
the canonical form output by the XML canonicalization method. If a the canonical form output by the XML canonicalization method. If a
canonical form contains comments corresponding to the comment nodes canonical form contains comments corresponding to the comment nodes
in the input node-set, the result is called canonical XML with in the input node-set, the result is called canonical XML with
comments. Note that the XPath data model does not create comment comments. Note that the XPath data model does not create comment
nodes for comments appearing within the document type declaration nodes for comments appearing within the document type declaration
(DTD). Implementations are REQUIRED to be capable of producing (DTD). Implementations are REQUIRED to be capable of producing
canonical XML excluding all comments that may have appeared in the canonical XML excluding all comments that may have appeared in the
input document or document subset. Support for canonical XML with input document or document subset. Support for canonical XML with
comments is RECOMMENDED. comments is RECOMMENDED.
If an XML document must be converted to a node-set, XPath REQUIRES 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 that an XML processor be used to create the nodes of its data model
to fully represent the document. The XML processor performs the to fully represent the document. The XML processor performs the
following tasks in order: following tasks in order:
1. normalize line feeds 1. normalize line feeds
2. normalize attribute values 2. normalize attribute values
3. replace CDATA sections with their character content 3. replace CDATA sections with their character content
4. resolve character and parsed entity references 4. resolve character and parsed entity references
The input octet stream MUST contain a well-formed XML document, but The input octet stream MUST contain a well-formed XML document, but
the input need not be validated. However, the attribute value the input need not be validated. However, the attribute value
normalization and entity reference resolution MUST be performed in normalization and entity reference resolution MUST be performed in
accordance with the behaviors of a validating XML processor. As well, accordance with the behaviors of a validating XML processor. As
nodes for default attributes (declared in the ATTLIST with an well, nodes for default attributes (declared in the ATTLIST with an
AttValue but not specified) are created in each element. Thus, the AttValue but not specified) are created in each element. Thus, the
declarations in the document type declaration are used to help create declarations in the document type declaration are used to help create
the canonical form, even though the document type declaration is not the canonical form, even though the document type declaration is not
retained in the canonical form. retained in the canonical form.
The XPath data model represents data using UCS characters. The XPath data model represents data using UCS characters.
Implementations MUST use XML processors that support UTF-8 and UTF-16 Implementations MUST use XML processors that support UTF-8 and UTF-16
and translate to the UCS character domain. For UTF-16, the leading and translate to the UCS character domain. For UTF-16, the leading
byte order mark is treated as an artifact of encoding and stripped byte order mark is treated as an artifact of encoding and stripped
from the UCS character data (subsequent zero width non-breaking from the UCS character data (subsequent zero width non-breaking
spaces appearing within the UTF-16 data are not removed) [UTF-16, 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 Section 3.2]. Support for ISO-8859-1 encoding is RECOMMENDED, and
other character encodings are OPTIONAL. all other character encodings are OPTIONAL.
All whitespace within the root document element MUST be preserved All whitespace within the root document element MUST be preserved
(except for any #xD characters deleted by line delimiter (except for any #xD characters deleted by line delimiter
normalization). This includes all whitespace in external entities. normalization). This includes all whitespace in external entities.
Whitespace outside of the root document element MUST be discarded. Whitespace outside of the root document element MUST be discarded.
In the XPath data model, there exist the following node types: root, In the XPath data model, there exist the following node types: root,
element, comment, processing instruction, text, attribute and element, comment, processing instruction, text, attribute and
namespace. There exists a single root node whose children are namespace. There exists a single root node whose children are
processing instruction nodes and comment nodes to represent processing instruction nodes and comment nodes to represent
information outside of the document element (and outside of the information outside of the document element (and outside of the
document type declaration). The root node also has a single element document type declaration). The root node also has a single element
node representing the top-level document element. Each element node node representing the top-level document element. Each element node
can have child nodes of type element, text, processing instruction, can have child nodes of type element, text, processing instruction,
and comment. The attributes and namespaces associated with an element and comment. The attributes and namespaces associated with an
are not considered to be child nodes of the element, but they are element are not considered to be child nodes of the element, but they
associated with the element by inclusion in the element's attribute are associated with the element by inclusion in the element's
and namespace axes. Note that attribute and namespace axes may not attribute and namespace axes. Note that attribute and namespace axes
directly correspond to the text appearing in the element's start tag may not directly correspond to the text appearing in the element's
in the original document. start tag in the original document.
Note: An element has attribute nodes to represent the non-namespace Note: An element has attribute nodes to represent the non-namespace
attribute declarations appearing in its start tag as well as attribute declarations appearing in its start tag as well as
nodes to represent the default attributes. nodes to represent the default attributes.
By virtue of the XPath data model, XML canonicalization is By virtue of the XPath data model, XML canonicalization is
namespace-aware [Names]. However, it cannot and therefore does not namespace-aware [Names]. However, it cannot and therefore does not
account for namespace equivalencies using namespace prefix rewriting account for namespace equivalencies using namespace prefix rewriting
(see explanation in Section 4). In the XPath data model, each element (see explanation in Section 4). In the XPath data model, each
and attribute has a name returned by the function name() which can, element and attribute has a name returned by the function name()
at the discretion of the application, be the QName appearing in the which can, at the discretion of the application, be the QName
original document. XML canonicalization REQUIRES that the XML appearing in the original document. XML canonicalization REQUIRES
processor retain sufficient information such that the QName of the that the XML processor retain sufficient information such that the
element as it appeared in the original document can be provided. QName of the element as it appeared in the original document can be
provided.
Note: An element E has namespace nodes that represent its namespace Note: An element E has namespace nodes that represent its namespace
declarations as well as any namespace declarations made by its declarations as well as any namespace declarations made by its
ancestors that have not been overridden in E's declarations, ancestors that have not been overridden in E's declarations,
the default namespace if it is non-empty, and the declaration the default namespace if it is non-empty, and the declaration
of the prefix xml. of the prefix xml. nn Note: This specification supports the
recent XML plenary decision to
Note: This specification supports the recent XML plenary decision to
deprecate relative namespace URIs as follows: implementations deprecate relative namespace URIs as follows: implementations
of XML canonicalization MUST report an operation failure on of XML canonicalization MUST report an operation failure on
documents containing relative namespace URIs. XML documents containing relative namespace URIs. XML
canonicalization MUST NOT be implemented with an XML parser canonicalization MUST NOT be implemented with an XML parser
that converts relative URIs to absolute URIs. that converts relative URIs to absolute URIs.
Character content is represented in the XPath data model with text Character content is represented in the XPath data model with text
nodes. All consecutive characters are placed into a single text nodes. All consecutive characters are placed into a single text
node. Furthermore, the text node's characters are represented in the node. Furthermore, the text node's characters are represented in the
UCS character domain. The XML canonicalization method does not UCS character domain. The XML canonicalization method does not
perform character model normalization (see explanation in Section 4). perform character model normalization (see explanation in Section 4).
However, the XML processor used to prepare the XPath data model input However, the XML processor used to prepare the XPath data model input
is REQUIRED to use Normalization Form C [NFC] when converting an XML is REQUIRED to use Normalization Form C [NFC, NFC-Corrigendum] when
document to the UCS character domain from any encoding that is not converting an XML document to the UCS character domain from any
UCS-based (currently, UCS-based encodings include UTF-8, UTF-16, encoding that is not UCS-based (currently, UCS-based encodings
UTF-16BE, and UTF-16LE, UCS-2, and UCS-4). include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and UCS-4).
Since XML canonicalization converts an XPath node-set into a Since XML canonicalization converts an XPath node-set into a
canonical form, the first parameter MUST either be an XPath node-set 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 or it must be converted from an octet stream to a node-set by
performing the XML processing necessary to create the XPath nodes performing the XML processing necessary to create the XPath nodes
described above, then setting an initial XPath evaluation context of: described above, then setting an initial XPath evaluation context of:
* A context node, initialized to the root node of the input XML * A context node, initialized to the root node of the input XML
document. document.
* A context position, initialized to 1. * A context position, initialized to 1.
skipping to change at page 10, line 42 skipping to change at page 9, line 39
(//. | //@* |//namespace::*)[not(self::comment())] (//. | //@* |//namespace::*)[not(self::comment())]
With (true): With (true):
(//. | //@* | //namespace::*) (//. | //@* | //namespace::*)
The expressions in this table generate a node-set containing every The expressions in this table generate a node-set containing every
node of the XML document (except the comments if the comment node of the XML document (except the comments if the comment
parameter value is false). parameter value is false).
If the input is an XPath node-set, then the node-set must explicitly 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, contain every node to be rendered to the canonical form. For
the result of the XPath expression id("E") is a node-set containing example, the result of the XPath expression id("E") is a node-set
only the node corresponding to the element with an ID attribute value containing only the node corresponding to the element with an ID
of "E". Since none of its descendant nodes, attribute nodes and attribute value of "E". Since none of its descendant nodes,
namespace nodes are in the set, the canonical form would consist attribute nodes and namespace nodes are in the set, the canonical
solely of the element's start and end tags, less the attribute and form would consist solely of the element's start and end tags, less
namespace declarations, with no internal content. Section 3.7 the attribute and namespace declarations, with no internal content.
exemplifies how to serialize an identified element along with its Section 3.7 exemplifies how to serialize an identified element along
internal content, attributes and namespace declarations. with its internal content, attributes and namespace declarations.
2.2 Document Order 2.2 Document Order
Although an XPath node-set is defined to be unordered, the XPath 1.0 Although an XPath node-set is defined to be unordered, the XPath 1.0
Recommendation [XPath] defines the term document order to be the Recommendation [XPath] defines the term document order to be the
order in which the first character of the XML representation of each order in which the first character of the XML representation of each
node occurs in the XML representation of the document after expansion node occurs in the XML representation of the document after expansion
of general entities, except for namespace and attribute nodes whose of general entities, except for namespace and attribute nodes whose
document order is application-dependent. document order is application-dependent.
The XML canonicalization method processes a node-set by imposing the The XML canonicalization method processes a node-set by imposing the
following additional document order rules on the namespace and following additional document order rules on the namespace and
attribute nodes of each element: attribute nodes of each element:
* An element's namespace and attribute nodes have a document order * An element's namespace and attribute nodes have a document
position greater than the element but less than any child node order position greater than the element but less than any child
of the element. node of the element.
* Namespace nodes have a lesser document order position than * Namespace nodes have a lesser document order position than
attribute nodes. attribute nodes.
* An element's namespace nodes are sorted lexicographically by * An element's namespace nodes are sorted lexicographically by
local name (the default namespace node, if one exists, has no local name (the default namespace node, if one exists, has no
local name and is therefore lexicographically least). local name and is therefore lexicographically least).
* An element's attribute nodes are sorted lexicographically with * An element's attribute nodes are sorted lexicographically with
namespace URI as the primary key and local name as the secondary namespace URI as the primary key and local name as the
key (an empty namespace URI is lexicographically least). secondary key (an empty namespace URI is lexicographically
least).
Lexicographic comparison, which orders strings from least to greatest Lexicographic comparison, which orders strings from least to greatest
alphabetically, is based on the UCS codepoint values, which is alphabetically, is based on the UCS codepoint values, which is
equivalent to lexicographic ordering based on UTF-8. equivalent to lexicographic ordering based on UTF-8.
2.3 Processing Model 2.3 Processing Model
The XPath node-set is converted into an octet stream, the canonical The XPath node-set is converted into an octet stream, the canonical
form, by generating the representative UCS characters for each node form, by generating the representative UCS characters for each node
in the node-set in ascending document order, then encoding the result 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 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 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. processing of all members of the node-set for which E is an ancestor.
Therefore, directly after the representative text for E is generated, Therefore, directly after the representative text for E is generated,
E and all nodes for which E is an ancestor are removed from the 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 (or some logically equivalent operation occurs such that the
node-set's next node in document order has not been processed). Note, node-set's next node in document order has not been processed).
however, that an element node is not removed from the node-set until Note, however, that an element node is not removed from the node-set
after its children are processed. until after its children are processed.
The result of processing a node depends on its type and on whether or 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 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 text is generated for the node except for the result of processing
its namespace and attribute axes (elements only) and its children its namespace and attribute axes (elements only) and its children
(elements and the root node). If the node is in the node-set, then (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 text is generated to represent the node in the canonical form in
addition to the text generated by processing the node's namespace and addition to the text generated by processing the node's namespace and
attribute axes and child nodes. attribute axes and child nodes.
Note: The node-set is treated as a set of nodes, not a list of Note: The node-set is treated as a set of nodes, not a list of
subtrees. To canonicalize an element including its namespaces, subtrees. To canonicalize an element including its namespaces,
attributes, and content, the node-set must actually contain all attributes, and content, the node-set must actually contain all
of the nodes corresponding to these parts of the document, not of the nodes corresponding to these parts of the document, not
just the element node. just the element node.
The text generated for a node is dependent on the node type and given The text generated for a node is dependent on the node type and given
in the following list: in the following list:
* Root Node- The root node is the parent of the top-level document * Root Node- The root node is the parent of the top-level
element. The result of processing each of its child nodes that document element. The result of processing each of its child
is in the node-set in document order. The root node does not nodes that is in the node-set in document order. The root node
generate a byte order mark, XML declaration, nor anything from does not generate a byte order mark, XML declaration, nor
within the document type declaration. anything from within the document type declaration.
* Element Nodes- If the element is not in the node-set, then the * Element Nodes- If the element is not in the node-set, then the
result is obtained by processing the namespace axis, then the result is obtained by processing the namespace axis, then the
attribute axis, then processing the child nodes of the element attribute axis, then processing the child nodes of the element
that are in the node-set (in document order). If the element is that are in the node-set (in document order). If the element
in the node-set, then the result is an open angle bracket (<), is in the node-set, then the result is an open angle bracket
the element QName, the result of processing the namespace axis, (<), the element QName, the result of processing the namespace
the result of processing the attribute axis, a close angle axis, the result of processing the attribute axis, a close
bracket (>), the result of processing the child nodes of the angle bracket (>), the result of processing the child nodes of
element that are in the node-set (in document order), an open the element that are in the node-set (in document order), an
angle bracket, a forward slash (/), the element QName, and a open angle bracket, a forward slash (/), the element QName, and
close angle bracket. a close angle bracket.
* *
o Namespace Axis- Consider a list L containing only namespace o Namespace Axis- Consider a list L containing only namespace
nodes in the axis and in the node-set in lexicographic order nodes in the axis and in the node-set in lexicographic order
(ascending). To begin processing L, if the first node is not (ascending). To begin processing L, if the first node is not
the default namespace node (a node with no namespace URI and the default namespace node (a node with no namespace URI and
no local name), then generate a space followed by xmlns="" no local name), then generate a space followed by xmlns="" if
if and only if the following conditions are met: and only if the following conditions are met:
+ the element E that owns the axis is in the node-set + the element E that owns the axis is in the node-set
+ The nearest ancestor element of E in the node-set has a + The nearest ancestor element of E in the node-set has a
default namespace node in the node-set (default namespace default namespace node in the node-set (default namespace
nodes always have non-empty values in XPath) nodes always have non-empty values in XPath)
The latter condition eliminates unnecessary occurrences of The latter condition eliminates unnecessary occurrences of
xmlns="" in the canonical form since an element only receives xmlns="" in the canonical form since an element only receives
an xmlns="" if its default namespace is empty and if it has an xmlns="" if its default namespace is empty and if it has
an immediate parent in the canonical form that has a non- an immediate parent in the canonical form that has a non-
empty default namespace. To finish processing L, simply empty default namespace. To finish processing L, simply
process every namespace node in L, except omit namespace node process every namespace node in L, except omit namespace node
with local name xml, which defines the xml prefix, if its with local name xml, which defines the xml prefix, if its
string value is http://www.w3.org/XML/1998/namespace. string value is http://www.w3.org/XML/1998/namespace.
o Attribute Axis- In lexicographic order (ascending), process o Attribute Axis- In lexicographic order (ascending), process
each node that is in the element's attribute axis and in the each node that is in the element's attribute axis and in the
node-set. node-set.
* Namespace Nodes- A namespace node N is ignored if the nearest * Namespace Nodes- A namespace node N is ignored if the nearest
ancestor element of the node's parent element that is in the 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 node-set has a namespace node in the node-set with the same
local name and value as N. Otherwise, process the namespace node local name and value as N. Otherwise, process the namespace
N in the same way as an attribute node, except assign the local node N in the same way as an attribute node, except assign the
name xmlns to the default namespace node if it exists (in XPath, local name xmlns to the default namespace node if it exists (in
the default namespace node has an empty URI and local name). XPath, the default namespace node has an empty URI and local
name).
* Attribute Nodes- a space, the node's QName, an equals sign, an * Attribute Nodes- a space, the node's QName, an equals sign, an
open quotation mark (double quote), the modified string value, open quotation mark (double quote), the modified string value,
and a close quotation mark (double quote). The string value of and a close quotation mark (double quote). The string value of
the node is modified by replacing all ampersands (&) with &amp;, the node is modified by replacing all ampersands (&) with
all open angle brackets (<) with &lt;, all quotation mark (double &amp;, all open angle brackets (<) with &lt;, all quotation
quote) characters with &quot;, and the whitespace characters #x9, mark (double quote) characters with &quot;, and the whitespace
#xA, and #xD, with character references. The character references characters #x9, #xA, and #xD, with character references. The
are written in uppercase hexadecimal with no leading zeroes (for character references are written in uppercase hexadecimal with
example, #xD is represented by the character reference &#xD;). no leading zeroes (for example, #xD is represented by the
character reference &#xD;).
* Text Nodes- the string value, except all ampersands are replaced * Text Nodes- the string value, except all ampersands are
by &amp;, all open angle brackets (<) are replaced by &lt;, all replaced by &amp;, all open angle brackets (<) are replaced by
closing angle brackets (>) are replaced by &gt;, and all #xD &lt;, all closing angle brackets (>) are replaced by &gt;, and
characters are replaced by &#xD;. all #xD characters are replaced by &#xD;.
* Processing Instruction (PI) Nodes- The opening PI symbol (<?), * Processing Instruction (PI) Nodes- The opening PI symbol (<?),
the PI target name of the node, a leading space and the string 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 value if it is not empty, and the closing PI symbol (?>). If
string value is empty, then the leading space is not added. the string value is empty, then the leading space is not added.
Also, a trailing #xA is rendered after the closing PI symbol for Also, a trailing #xA is rendered after the closing PI symbol
PI children of the root node with a lesser document order than for PI children of the root node with a lesser document order
the document element, and a leading #xA is rendered before the than the document element, and a leading #xA is rendered before
opening PI symbol of PI children of the root node with a greater the opening PI symbol of PI children of the root node with a
document order than the document element. greater document order than the document element.
* Comment Nodes- Nothing if generating canonical XML without * Comment Nodes- Nothing if generating canonical XML without
comments. For canonical XML with comments, generate the opening comments. For canonical XML with comments, generate the
comment symbol (<!--), the string value of the node, and the opening comment symbol (<!--), the string value of the node,
closing comment symbol (-->). Also, a trailing #xA is rendered and the closing comment symbol (-->). Also, a trailing #xA is
after the closing comment symbol for comment children of the rendered after the closing comment symbol for comment children
root node with a lesser document order than the document of the root node with a lesser document order than the document
element, and a leading #xA is rendered before the opening element, and a leading #xA is rendered before the opening
comment symbol of comment children of the root node with a comment symbol of comment children of the root node with a
greater document order than the document element. (Comment greater document order than the document element. (Comment
children of the root node represent comments outside of the children of the root node represent comments outside of the
top-level document element and outside of the document type top-level document element and outside of the document type
declaration). declaration.)
The QName of a node is either the local name if the namespace prefix 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 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 of the element. The namespace prefix used in the QName MUST be the
same one which appeared in the input document. same one which appeared in the input document.
2.4 Document Subsets 2.4 Document Subsets
Some applications require the ability to create a physical Some applications require the ability to create a physical
representation for an XML document subset (other than the one representation for an XML document subset (other than the one
generated by default, which can be a proper subset of the document if generated by default, which can be a proper subset of the document if
the comments are omitted). Implementations of XML canonicalization the comments are omitted). Implementations of XML canonicalization
that are based on XPath can provide this functionality with little that are based on XPath can provide this functionality with little
additional overhead by accepting a node-set as input rather than an additional overhead by accepting a node-set as input rather than an
octet stream. octet stream.
The processing of an element node E MUST be modified slightly when an 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 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 from the node-set. The method for processing the attribute axis of
element E in the node-set is enhanced. All element nodes along E's an element E in the node-set is enhanced. All element nodes along
ancestor axis are examined for nearest occurrences of attributes in E's ancestor axis are examined for nearest occurrences of attributes
the xml namespace, such as xml:lang and xml:space (whether or not 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 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- that are in E's attribute axis (whether or not they are in the node-
set). Then, lexicographically merge this attribute list with the set). Then, lexicographically merge this attribute list with the
nodes of E's attribute axis that are in the node-set. The result of 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 visiting the attribute axis is computed by processing the attribute
nodes in this merged attribute list. nodes in this merged attribute list.
Note: XML entities can derive application-specific meaning from Note: XML entities can derive application-specific meaning from
anywhere in the XML markup as well as by rules not expressed in anywhere in the XML markup as well as by rules not expressed
XML 1.0 and the Namespaces Recommendations. Clearly, these in XML 1.0 and the Namespaces Recommendations. Clearly,
rules cannot be specified in this document, so the creator of these rules cannot be specified in this document, so the
the input node-set must be responsible for preserving the creator of the input node-set must be responsible for
information necessary to capture the full semantics of the preserving the information necessary to capture the full
members of the resulting node-set. semantics of the members of the resulting node-set.
The canonical XML generated for an entire XML document is well- The canonical XML generated for an entire XML document is well-
formed. The canonical form of an XML document subset may not be formed. The canonical form of an XML document subset may not be
well-formed XML. However, since the canonical form may be subjected well-formed XML. However, since the canonical form may be subjected
to further XML processing, most XPath node-sets provided for to further XML processing, most XPath node-sets provided for
canonicalization will be designed to produce a canonical form that is canonicalization will be designed to produce a canonical form that is
a well-formed XML document or external general parsed entity. Whether a well-formed XML document or external general parsed entity.
from a full document or a document subset, if the canonical form is Whether from a full document or a document subset, if the canonical
well-formed XML, then subsequent applications of the same XML form is well-formed XML, then subsequent applications of the same XML
canonicalization method to the canonical form make no changes. canonicalization method to the canonical form make no changes.
3 Examples of XML Canonicalization 3. Examples of XML Canonicalization
The examples in this section assume a non-validating processor, The examples in this section assume a non-validating processor,
primarily so that a document type declaration can be used to declare primarily so that a document type declaration can be used to declare
entities as well as default attributes and attributes of various entities as well as default attributes and attributes of various
types (such as ID and enumerated) without having to declare all types (such as ID and enumerated) without having to declare all
attributes for all elements in the document. As well, one example attributes for all elements in the document. As well, one example
contains an element that deliberately violates a validity constraint contains an element that deliberately violates a validity constraint
(because it is still well-formed). (because it is still well-formed).
3.1 PIs, Comments, and Outside of Document Element 3.1 PIs, Comments, and Outside of Document Element
Input Document Input Document
<?xml version="1.0"?> --------------
<?xml version="1.0"?>
<?xml-stylesheet href="doc.xsl" <?xml-stylesheet href="doc.xsl"
type="text/xsl" ?> type="text/xsl" ?>
<!DOCTYPE doc SYSTEM "doc.dtd"> <!DOCTYPE doc SYSTEM "doc.dtd">
<doc>Hello, world!<!-- Comment 1 --></doc> <doc>Hello, world!<!-- Comment 1 --></doc>
<?pi-without-data ?> <?pi-without-data ?>
<!-- Comment 2 --> <!-- Comment 2 -->
<!-- Comment 3 --> <!-- Comment 3 -->
Canonical Form (uncommented) Canonical Form (uncommented)
<?xml-stylesheet href="doc.xsl" ----------------------------
type="text/xsl" ?> <?xml-stylesheet href="doc.xsl"
<doc>Hello, world!</doc> type="text/xsl" ?>
<?pi-without-data?> <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 -->
Canonical Form (commented)
<?xml-stylesheet href="doc.xsl"
type="text/xsl" ?>
<doc>Hello, world!<!-- Comment 1 --></doc>
<?pi-without-data?>
<!-- Comment 2 -->
<!-- Comment 3 -->
Demonstrates: Demonstrates:
* Loss of XML declaration * Loss of XML declaration
* Loss of DTD * Loss of DTD
* Normalization of whitespace outside of document element (first * Normalization of whitespace outside of document element (first
character of both canonical forms is '<'; single line breaks character of both canonical forms is '<'; single line breaks
separate PIs and comments outside of document element) separate PIs and comments outside of document element)
* Loss of whitespace between PITarget and its data * Loss of whitespace between PITarget and its data * Retention of
* Retention of whitespace inside PI data whitespace inside PI data
* Comment removal from uncommented canonical form, including * Comment removal from uncommented canonical form, including
delimiter for comments outside document element (the last delimiter for comments outside document element (the last
character in both canonical forms is '>') character in both canonical forms is '>')
3.2 Whitespace in Document Content 3.2 Whitespace in Document Content
Input Document Input Document
<doc> --------------
<clean> </clean> <doc>
<dirty> A B </dirty>
<mixed>
A
<clean> </clean> <clean> </clean>
B
<dirty> A B </dirty> <dirty> A B </dirty>
C <mixed>
</mixed> A
</doc> <clean> </clean>
B
<dirty> A B </dirty>
C
</mixed>
</doc>
Canonical Form Canonical Form
<doc> --------------
<clean> </clean> <doc>
<dirty> A B </dirty>
<mixed>
A
<clean> </clean> <clean> </clean>
B
<dirty> A B </dirty> <dirty> A B </dirty>
C <mixed>
</mixed> A
</doc> <clean> </clean>
B
<dirty> A B </dirty>
C
</mixed>
</doc>
Demonstrates: Demonstrates:
* Retain all whitespace between consecutive start tags, clean or * Retain all whitespace between consecutive start tags, clean or
dirty dirty
* Retain all whitespace between consecutive end tags, clean or * Retain all whitespace between consecutive end tags, clean or
dirty dirty
* Retain all whitespace between end tag/start tag pair, clean or * Retain all whitespace between end tag/start tag pair, clean or
dirty dirty
* Retain all whitespace in character content, clean or dirty * Retain all whitespace in character content, clean or dirty
Note: In this example, the input document and canonical form are Note: In this example, the input document and canonical form are
identical. Both end with '>' character. identical. Both end with '>' character.
3.3 Start and End Tags 3.3 Start and End Tags
Input Document Input Document
-------------- --------------
<!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]> <!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]>
<doc> <doc>
<e1 /> <e1 />
<e2 ></e2> <e2 ></e2>
<e3 name = "elem3" id="elem3" /> <e3 name = "elem3" id="elem3" />
<e4 name="elem4" id="elem4" ></e4> <e4 name="elem4" id="elem4" ></e4>
<e5 a:attr="out" b:attr="sorted" attr2="all" attr="I'm" <e5 a:attr="out" b:attr="sorted" attr2="all" attr="I'm"
xmlns:b="http://www.ietf.org" xmlns:b="http://www.ietf.org"
xmlns:a="http://www.w3.org" xmlns:a="http://www.w3.org"
xmlns="http://www.uvic.ca"/> xmlns="http://example.org"/>
<e6 xmlns="" xmlns:a="http://www.w3.org"> <e6 xmlns="" xmlns:a="http://www.w3.org">
<e7 xmlns="http://www.ietf.org"> <e7 xmlns="http://www.ietf.org">
<e8 xmlns="" xmlns:a="http://www.w3.org"> <e8 xmlns="" xmlns:a="http://www.w3.org">
<e9 xmlns="" xmlns:a="http://www.ietf.org"/> <e9 xmlns="" xmlns:a="http://www.ietf.org"/>
</e8> </e8>
</e7> </e7>
</e6> </e6>
</doc> </doc>
Canonical Form Canonical Form
-------------- --------------
<doc> <doc>
<e1></e1> <e1></e1>
<e2></e2> <e2></e2>
<e3 id="elem3" name="elem3"></e3> <e3 id="elem3" name="elem3"></e3>
<e4 id="elem4" name="elem4"></e4> <e4 id="elem4" name="elem4"></e4>
<e5 xmlns="http://www.uvic.ca" xmlns:a="http://www.w3.org" <e5 xmlns="http://example.org" xmlns:a="http://www.w3.org"
xmlns:b="http://www.ietf.org" attr="I'm" attr2="all" xmlns:b="http://www.ietf.org" attr="I'm" attr2="all"
b:attr="sorted" a:attr="out"></e5> b:attr="sorted" a:attr="out"></e5>
<e6 xmlns:a="http://www.w3.org"> <e6 xmlns:a="http://www.w3.org">
<e7 xmlns="http://www.ietf.org"> <e7 xmlns="http://www.ietf.org">
<e8 xmlns=""> <e8 xmlns="">
<e9 xmlns:a="http://www.ietf.org" attr="default"></e9> <e9 xmlns:a="http://www.ietf.org" attr="default"></e9>
</e8> </e8>
</e7> </e7>
</e6> </e6>
</doc> </doc>
Demonstrates: Demonstrates:
* Empty element conversion to start-end tag pair * Empty element conversion to start-end tag pair
* Normalization of whitespace in start and end tags * Normalization of whitespace in start and end tags
* Relative order of namespace and attribute axes * Relative order of namespace and attribute axes
* Lexicographic ordering of namespace and attribute axes * Lexicographic ordering of namespace and attribute axes
* Retention of namespace prefixes from original document * Retention of namespace prefixes from original document
* Elimination of superfluous namespace declarations * Elimination of superfluous namespace declarations
* Addition of default attribute * Addition of default attribute
Note: Some start tags in the canonical form are very long, but each Note: Some start tags in the canonical form are very long, but each
start tag in this example is entirely on a single line. start tag in this example is entirely on a single line.
Note: In e5, b:attr precedes a:attr because the primary key is Note: In e5, b:attr precedes a:attr because the primary key is
namespace URI not namespace prefix, and attr2 precedes b:attr namespace URI not namespace prefix, and attr2 precedes b:attr
because the default namespace is not applied to unqualified because the default namespace is not applied to unqualified
attributes (so the namespace URI for attr2 is empty). attributes (so the namespace URI for attr2 is empty).
3.4 Character Modifications and Character References 3.4 Character Modifications and Character References
Input Document Input Document
-------------- --------------
<!DOCTYPE doc [ <!DOCTYPE doc [
<!ATTLIST normId id ID #IMPLIED> <!ATTLIST normId id ID #IMPLIED>
<!ATTLIST normNames attr NMTOKENS #IMPLIED> <!ATTLIST normNames attr NMTOKENS #IMPLIED>
]> ]>
<doc> <doc>
<text>First line&#x0d;&#10;Second line</text> <text>First line&#x0d;&#10;Second line</text>
<value>&#x32;</value> <value>&#x32;</value>
<compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]></compute> <compute><![CDATA[value>"0" && value<"10" ?"valid":"error"]]>
</compute>
<compute expr='value>"0" &amp;&amp; value&lt;"10" <compute expr='value>"0" &amp;&amp; value&lt;"10"
?"valid":"error"'>valid</compute> ?"valid":"error"'>valid</compute>
<norm attr=' &apos; &#x20;&#13;&#xa;&#9; &apos; '/> <norm attr=' &apos; &#x20;&#13;&#xa;&#9; &apos; '/>
<normNames attr=' A &#x20;&#13;&#xa;&#9; B '/> <normNames attr=' A &#x20;&#13;&#xa;&#9; B '/>
<normId id=' &apos; &#x20;&#13;&#xa;&#9; &apos; '/> <normId id=' &apos; &#x20;&#13;&#xa;&#9; &apos; '/>
</doc> </doc>
Canonical Form Canonical Form
-------------- --------------
<doc> <doc>
<text>First line&#xD; <text>First line&#xD;
Second line</text> Second line</text>
<value>2</value> <value>2</value>
<compute>value&gt;"0" &amp;&amp; value&lt;"10" ?"valid":"error"</compute> <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; <compute expr="value>&quot;0&quot; &amp;&amp; value&lt;&quot;10&quot;
?&quot; ?&quot;
valid&quot;:&quot;error&quot;">valid</compute> valid&quot;:&quot;error&quot;">valid</compute>
<norm attr=" ' &#xD;&#xA;&#x9; ' "></norm> <norm attr=" ' &#xD;&#xA;&#x9; ' "></norm>
<normNames attr="A &#xD;&#xA;&#x9; B"></normNames> <normNames attr="A &#xD;&#xA;&#x9; B"></normNames>
<normId id="' &#xD;&#xA;&#x9; '"></normId> <normId id="' &#xD;&#xA;&#x9; '"></normId>
</doc> </doc>
Demonstrates: Demonstrates:
* Character reference replacement * Character reference replacement
* Attribute value delimiters set to quotation marks (double * Attribute value delimiters set to quotation marks (double
quotes) quotes)
* Attribute value normalization * Attribute value normalization
* CDATA section replacement * CDATA section replacement
* Encoding of special characters as character references in * Encoding of special characters as character references in
attribute values (&amp;, &lt;, &quot;, &#xD;, &#xA;, &#x9;) attribute values (&amp;, &lt;, &quot;, &#xD;, &#xA;, &#x9;)
* Encoding of special characters as character references in text * Encoding of special characters as character references in text
(&amp;, &lt;, &gt;, &#xD;) (&amp;, &lt;, &gt;, &#xD;)
Note: The last element, normId, is well-formed but violates a Note: The last element, normId, is well-formed but violates a
validity constraint for attributes of type ID. For testing validity constraint for attributes of type ID. For testing
canonical XML implementations based on validating processors, canonical XML implementations based on validating processors,
remove the line containing this element from the input and remove the line containing this element from the input and
canonical form. In general, XML consumers should be discouraged canonical form. In general, XML consumers should be
from using this feature of XML. discouraged from using this feature of XML.
Note: Whitespace characters references other than &#x20; are not Note: Whitespace characters references other than &#x20; are not
affected by attribute value normalization [XML]. affected by attribute value normalization [XML].
Note: In the canonical form, the value of the attribute named attr in 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 the element norm begins with a space, a single quote, then four
spaces before the first character reference. spaces before the first character reference.
Note: The expr attribute of the second compute element contains no Note: The expr attribute of the second compute element contains no
line breaks. line breaks.
3.5 Entity References 3.5 Entity References
Input Document Input Document
<!DOCTYPE doc [ --------------
<!ATTLIST doc attrExtEnt ENTITY #IMPLIED> <!DOCTYPE doc [
<!ENTITY ent1 "Hello"> <!ATTLIST doc attrExtEnt ENTITY #IMPLIED>
<!ENTITY ent2 SYSTEM "world.txt"> <!ENTITY ent1 "Hello">
<!ENTITY entExt SYSTEM "earth.gif" NDATA gif> <!ENTITY ent2 SYSTEM "world.txt">
<!NOTATION gif SYSTEM "viewgif.exe"> <!ENTITY entExt SYSTEM "earth.gif" NDATA gif>
]> <!NOTATION gif SYSTEM "viewgif.exe">
<doc attrExtEnt="entExt"> ]>
&ent1;, &ent2;! <doc attrExtEnt="entExt">
</doc> &ent1;, &ent2;!
</doc>
<!-- Let world.txt contain "world" (excluding the quotes) --> <!-- Let world.txt contain "world" (excluding the quotes) -->
Canonical Form (uncommented) Canonical Form (uncommented)
<doc attrExtEnt="entExt"> ----------------------------
Hello, world! <doc attrExtEnt="entExt">
</doc> Hello, world!
</doc>
Demonstrates: Demonstrates:
* Internal parsed entity reference replacement * Internal parsed entity reference replacement
* External parsed entity reference replacement (including * External parsed entity reference replacement (including
whitespace outside elements and PIs) whitespace outside elements and PIs)
* External unparsed entity reference * External unparsed entity reference
3.6 UTF-8 Encoding 3.6 UTF-8 Encoding
Input Document Input Document
<?xml version="1.0" encoding="ISO-8859-1"?> --------------
<doc>&#169;</doc> <?xml version="1.0" encoding="ISO-8859-1"?>
<doc>&#169;</doc>
Canonical Form Canonical Form
<doc>#xC2#xA9</doc> --------------
<doc>#xC2#xA9</doc>
Demonstrates: Demonstrates:
* Effect of transcoding from a sample encoding to UTF-8 * Effect of transcoding from a sample encoding to UTF-8
Note: The content of the doc element is NOT the string #xC2#xA9 but 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, rather the two octets whose hexadecimal values are C2 and A9,
which is the UTF-8 encoding of the UCS codepoint for the which is the UTF-8 encoding of the UCS codepoint for the
copyright symbol (c). copyright symbol (c).
3.7 Document Subsets 3.7 Document Subsets
Input Document Input Document
-------------- --------------
skipping to change at page 22, line 4 skipping to change at page 20, line 35
Document Subset Expression Document Subset Expression
-------------------------- --------------------------
(//. | //@* | //namespace::*) (//. | //@* | //namespace::*)
[ <br/> [ <br/>
self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2)) self::ietf:e1 or (parent::ietf:e1 and not(self::text() or self::e2))
or or
count(id("E3")|ancestor-or-self::node()) = count(id("E3")|ancestor-or-self::node()) =
count(ancestor-or-self::node()) count(ancestor-or-self::node())
] ]
Canonical Form Canonical Form
-------------- --------------
<e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3 <e1 xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"><e3
xmlns="" id="E3" xml:space="preserve"></e3></e1> xmlns="" id="E3" xml:space="preserve"></e3></e1>
Demonstrates: Demonstrates:
* Empty default namespace propagation from omitted parent element * Empty default namespace propagation from omitted parent
* Propagation of attributes in xml namespace in document subsets element * Propagation of attributes in xml namespace in
* Persistence of omitted namespace declarations in descendants document subsets * Persistence of omitted namespace
declarations in descendants
Note: In the document subset expression, the subexpression (//. | Note: In the document subset expression, the subexpression (//. |
//@* | //namespace::*) selects all nodes in the input document, //@* | //namespace::*) selects all nodes in the input document,
subjecting each to the predicate expression in square brackets. subjecting each to the predicate expression in square brackets.
The expression is true for e1 and its implicit namespace nodes, The expression is true for e1 and its implicit namespace nodes,
and it is true if the element identified by E3 is in the and it is true if the element identified by E3 is in the
ancestor-or-self path of the context node (such that ancestor- ancestor-or-self path of the context node (such that ancestor-
or-self stays the same size under union with the element or-self stays the same size under union with the element
identified by E3). identified by E3).
Note: The canonical form contains no line delimiters. Note: The canonical form contains no line delimiters.
4 Resolutions 4. Resolutions
This section discusses a number of key decision points as well as a This section discusses a number of key decision points as well as a
rationale for each decision. Although this specification now defines rationale for each decision. Although this specification now defines
XML canonicalization in terms of the XPath data model rather than XML XML canonicalization in terms of the XPath data model rather than XML
Infoset, the canonical form described in this document is quite Infoset, the canonical form described in this document is quite
similar in most respects to the canonical form described in the similar in most respects to the canonical form described in the
January 2000 Canonical XML draft [C14N-20000119]. However, some January 2000 Canonical XML draft [C14N-20000119]. However, some
differences exist, and a number of the subsections discuss the differences exist, and a number of the subsections discuss the
changes. changes.
4.1 No XML Declaration 4.1 No XML Declaration
The XML declaration, including version number and character encoding The XML declaration, including version number and character encoding
is omitted from the canonical form. The encoding is not needed since 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 the canonical form is encoded in UTF-8. The version is not needed
since the absence of a version number unambiguously indicates XML since the absence of a version number unambiguously indicates XML
1.0. 1.0.
Future versions of XML will be required to include an XML declaration Future versions of XML will be required to include an XML declaration
to indicate the version number. However, canonicalization method to indicate the version number. However, canonicalization method
described in this specification may not be applicable to future described in this specification may not be applicable to future
versions of XML without some modifications. When canonicalization of versions of XML without some modifications. When canonicalization of
a new version of XML is required, this specification could be updated a new version of XML is required, this specification could be updated
to include the XML declaration as presumably the absence of the XML to include the XML declaration as presumably the absence of the XML
declaration from the XPath data model can be remedied by that time 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). (e.g., by reissuing a new XPath based on the Infoset data model).
4.2 No Character Model Normalization 4.2 No Character Model Normalization
The Unicode standard [Unicode] allows multiple different The Unicode standard [Unicode] allows multiple different
representations of certain "precomposed characters" (a simple example representations of certain "precomposed characters" (a simple example
is +U00E7, "LATIN SMALL LETTER C WITH CEDILLA"). Thus two XML is +U00E7, "LATIN SMALL LETTER C WITH CEDILLA"). Thus two XML
documents with content that is equivalent for the purposes of most documents with content that is equivalent for the purposes of most
applications may contain differing character sequences. The W3C is applications may contain differing character sequences. The W3C is
preparing a normalized representation [CharModel]. The C14N-20000119 preparing a normalized representation [CharModel]. The C14N-20000119
Canonical XML draft used this normalized form. However, many XML 1.0 Canonical XML draft used this normalized form. However, many XML 1.0
processors do not perform this normalization. Furthermore, processors do not perform this normalization. Furthermore,
applications that must solve this problem typically enforce character applications that must solve this problem typically enforce character
model normalization at all times starting when character content is model normalization at all times starting when character content is
created in order to avoid processing failures that could otherwise created in order to avoid processing failures that could otherwise
result (e.g. see example from Cowan). Therefore, character model result (e.g., see example from Cowan). Therefore, character model
normalization has been moved out of scope for XML canonicalization. normalization has been moved out of scope for XML canonicalization.
However, the XML processor used to prepare the XPath data model input However, the XML processor used to prepare the XPath data model input
is required (by the Data Model) to use Normalization Form C [NFC] is required (by the Data Model) to use Normalization Form C [NFC,
when converting an XML document to the UCS character domain from any NFC-Corrigendum] when converting an XML document to the UCS character
encoding that is not UCS-based (currently, UCS-based encodings include domain from any encoding that is not UCS-based (currently, UCS-based
UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and UCS-4). encodings include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2, and
UCS-4).
4.3 Handling of Whitespace Outside Document Element 4.3 Handling of Whitespace Outside Document Element
The C14N-20000119 Canonical XML draft placed a #xA after each PI 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 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 the document element. The method in this specification performs the
same function except for omitting the final #xA after the last PI (or same function except for omitting the final #xA after the last PI (or
comment or end tag of the document element). This technique ensures comment or end tag of the document element). This technique ensures
that PI (and comment) children of the root are separated from markup 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 by a line feed even if root node or the document element are omitted
from the output node-set. from the output node-set.
4.4 No Namespace Prefix Rewriting 4.4 No Namespace Prefix Rewriting
The C14N-20000119 Canonical XML draft described a method for The C14N-20000119 Canonical XML draft described a method for
rewriting namespace prefixes such that two documents having logically rewriting namespace prefixes such that two documents having logically
equivalent namespace declarations would also have identical namespace equivalent namespace declarations would also have identical namespace
prefixes. The goal was to eliminate dependence on the particular prefixes. The goal was to eliminate dependence on the particular
namespace prefixes in a document when testing for logical namespace prefixes in a document when testing for logical
equivalence. However, there now exist a number of contexts in which equivalence. However, there now exist a number of contexts in which
namespace prefixes can impart information value in an XML document. namespace prefixes can impart information value in an XML document.
For example, an XPath expression in an attribute value or element For example, an XPath expression in an attribute value or element
content can reference a namespace prefix. Thus, rewriting the content can reference a namespace prefix. Thus, rewriting the
namespace prefixes would damage such a document by changing its namespace prefixes would damage such a document by changing its
meaning (and it cannot be logically equivalent if its meaning has meaning (and it cannot be logically equivalent if its meaning has
changed). changed).
More formally, let D1 be a document containing an XPath in an More formally, let D1 be a document containing an XPath in an
attribute value or element content that refers to namespace prefixes attribute value or element content that refers to namespace prefixes
used in D1. Further assume that the namespace prefixes in D1 will used in D1. Further assume that the namespace prefixes in D1 will
all be rewritten by the canonicalization method. Let D23D D1, then all be rewritten by the canonicalization method. Let D23D D1, then
modify the namespace prefixes in D2 and modify the XPath expression's modify the namespace prefixes in D2 and modify the XPath expression's
references to namespace prefixes such that D2 and D1 remain logically references to namespace prefixes such that D2 and D1 remain logically
equivalent. Since namespace rewriting does not include occurrences of equivalent. Since namespace rewriting does not include occurrences
namespace references in attribute values and element content, the of namespace references in attribute values and element content, the
canonical form of D1 does not equal the canonical form of D2 because canonical form of D1 does not equal the canonical form of D2 because
the XPath will be different. Thus, although namespace rewriting the XPath will be different. Thus, although namespace rewriting
normalizes the namespace declarations, the goal eliminating normalizes the namespace declarations, the goal eliminating
dependence on the particular namespace prefixes in the document is dependence on the particular namespace prefixes in the document is
not achieved. not achieved.
Moreover, it is possible to prove that namespace rewriting is Moreover, it is possible to prove that namespace rewriting is
harmful, rather than simply ineffective. Let D1 be a document harmful, rather than simply ineffective. Let D1 be a document
containing an XPath in an attribute value or element content that containing an XPath in an attribute value or element content that
refers to namespace prefixes used in D1. Further assume that the refers to namespace prefixes used in D1. Further assume that the
namespace prefixes in D1 will all be rewritten by the namespace prefixes in D1 will all be rewritten by the
canonicalization method. Now let D2 be the canonical form of D1. canonicalization method. Now let D2 be the canonical form of D1.
Clearly, the canonical forms of D1 and D2 are equivalent (since D2 is 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 the canonical form of the canonical form of D1), yet D1 and D2 are
not logically equivalent because the aforementioned XPath works in D1 not logically equivalent because the aforementioned XPath works in D1
and doesn't work in D2. and doesn't work in D2.
Note that an argument similar to this can be leveled against the XML Note that an argument similar to this can be leveled against the XML
canonicalization method based on any of the cases in the Limitations, canonicalization method based on any of the cases in the Limitations,
the problems cannot easily be fixed in those cases, whereas here we the problems cannot easily be fixed in those cases, whereas here we
have an opportunity to avoid purposefully introducing such a have an opportunity to avoid purposefully introducing such a
limitation. limitation.
Applications that must test for logical equivalence must perform more Applications that must test for logical equivalence must perform more
sophisticated tests than mere octet stream comparison. However, this sophisticated tests than mere octet stream comparison. However, this
is quite likely to be necessary in any case in order to test for is quite likely to be necessary in any case in order to test for
logical equivalencies based on application rules as well as rules logical equivalencies based on application rules as well as rules
from other XML-related recommendations, working drafts, and future from other XML-related recommendations, working drafts, and future
works. works.
4.5 Order of Namespace Declarations and Attributes 4.5 Order of Namespace Declarations and Attributes
The C14N-20000119 Canonical XML draft alternated between namespace The C14N-20000119 Canonical XML draft alternated between namespace
declarations and attribute declarations. This is part of the declarations and attribute declarations. This is part of the
namespace prefix rewriting scheme, which this specification namespace prefix rewriting scheme, which this specification
eliminates. This specification follows the XPath data model of eliminates. This specification follows the XPath data model of
putting all namespace nodes before all attribute nodes. putting all namespace nodes before all attribute nodes.
4.6 Superfluous Namespace Declarations 4.6 Superfluous Namespace Declarations
Unnecessary namespace declarations are not made in the canonical Unnecessary namespace declarations are not made in the canonical
form. Whether for an empty default namespace, a non-empty default form. Whether for an empty default namespace, a non-empty default
namespace, or a namespace prefix binding, the XML canonicalization namespace, or a namespace prefix binding, the XML canonicalization
method omits a declaration if it determines that the immediate parent method omits a declaration if it determines that the immediate parent
element in the canonical form has an equivalent declaration in scope. element in the canonical form has an equivalent declaration in scope.
The root document element is handled specially since it has no parent The root document element is handled specially since it has no parent
element. All namespace declarations in it are retained, except the element. All namespace declarations in it are retained, except the
declaration of an empty default namespace is automatically omitted. declaration of an empty default namespace is automatically omitted.
Relative to the method of simply rendering the entire namespace Relative to the method of simply rendering the entire namespace
context of each element, implementations are not hindered by more context of each element, implementations are not hindered by more
than a constant factor in processing time and memory use. The than a constant factor in processing time and memory use. The
advantages include: advantages include:
* Eliminates overrun of xmlns="" from canonical forms of * Eliminates overrun of xmlns="" from canonical forms of
applications that may not even use namespaces, or support them applications that may not even use namespaces, or support them
only minimally. only minimally.
* Eliminates namespace declarations from elements where they may * Eliminates namespace declarations from elements where they may
not belong according to the application's content model, thereby not belong according to the application's content model,
simplifying the task of reattaching a document type declaration thereby simplifying the task of reattaching a document type
to a canonical form. declaration to a canonical form.
Note that in document subsets, an element with omissions from its Note that in document subsets, an element with omissions from its
ancestral element chain will be rendered to the canonical form with ancestral element chain will be rendered to the canonical form with
namespace declarations that may have been made in its omitted namespace declarations that may have been made in its omitted
ancestors, thus preserving the meaning of the element. ancestors, thus preserving the meaning of the element.
4.7 Propagation of Default Namespace Declaration in Document Subsets 4.7 Propagation of Default Namespace Declaration in Document Subsets
The XPath data model represents an empty default namespace with the The XPath data model represents an empty default namespace with the
absence of a node, not with the presence of a default namespace node 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 having an empty value. Thus, with respect to the fact that element
in the following examples is not namespace qualified, we cannot tell e3 in the following examples is not namespace qualified, we cannot
the difference between <e1 xmlns="a:b"><e2 xmlns=""><e3/></e2></e1> tell the difference between <e1 xmlns="a:b"><e2
versus <e1 xmlns="a:b"><e2><e3 xmlns=""/></e2></e1>. All we know is xmlns=""><e3/></e2></e1> versus <e1 xmlns="a:b"><e2><e3
that e3 was not namespace qualified on input, so we preserve this xmlns=""/></e2></e1>. All we know is that e3 was not namespace
information on output if e2 is omitted so that e3 does not take on qualified on input, so we preserve this information on output if e2
the default namespace qualification of e1. is omitted so that e3 does not take on the default namespace
qualification of e1.
4.8 Sorting Attributes by Namespace URI 4.8 Sorting Attributes by Namespace URI
Given the requirement to preserve the namespace prefixes declared in Given the requirement to preserve the namespace prefixes declared in
a document, sorting attributes with the prefix, rather than the a document, sorting attributes with the prefix, rather than the
namespace URI, as the primary key is viable and easier to implement. namespace URI, as the primary key is viable and easier to implement.
However, the namespace URI was selected as the primary key because However, the namespace URI was selected as the primary key because
this is closer to the intent of the XML Names specification, which is 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 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 local name. The effect of the sort is to group together all
attributes that are in the same namespace. attributes that are in the same namespace.
Security Considerations
Security issues are discussed in section 1.3.
References References
[C14N-20000119] Canonical XML Version 1.0, W3C Working Draft. T. [C14N-20000119] Canonical XML Version 1.0, W3C Working Draft.
Bray, J. Clark, J. Tauber, and J. Cowan. January 19, 2000. T. Bray, J. Clark, J. Tauber, and J. Cowan.
http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html. January 19, 2000.
http://www.w3.org/TR/2000/WD-xml-c14n-
20000119.html.
[CharModel] Character Model for the World Wide Web, W3C Working [CharModel] Working Draft. eds. Martin J. Durst, Francois
Draft. eds. Martin J. Durst, Francois Yergeau. Yergeau, Misha Wolf, Asmus Freytag, Tex Texin.
http://www.w3.org/TR/charmod/. http://www.w3.org/TR/charmod/.
[Cowan] Example of Harmful Effect of Character Model Normalization, [Cowan] Example of Harmful Effect of Character Model
Letter in XML Signature Working Group Mail Archive. John Cowan, Normalization, Letter in XML Signature Working
July 7, 2000 http://lists.w3.org/Archives/Public/w3c-ietf- Group Mail Archive. John Cowan, July 7, 2000
xmldsig/2000JulSep/0038.html. http://lists.w3.org/Archives/Public/w3c-ietf-
xmldsig/2000JulSep/0038.html.
[Infoset] XML Information Set, W3C Working Draft. ed. John Cowan. [Infoset] XML Information Set, W3C Working Draft. John
http://www.w3.org/TR/xml-infoset. Cowan, Richard Tobin.
http://www.w3.org/TR/xml-infoset.
[ISO-8859-1] ISO-8859-1 Latin 1 Character Set. [ISO-8859-1] ISO-8859-1 Latin 1 Character Set.
http://www.utoronto.ca/webdocs/HTMLdocs/NewHTML/iso_table.html or http://www.utoronto.ca/webdocs/HTMLdocs/
http://www.iso.ch/cate/cat.html. NewHTML/iso_table.html or
http://www.iso.ch/cate/cat.html.
[Keywords] Key words for use in RFCs to Indicate Requirement Levels, [Keywords] Bradner, S., "Key words for use in RFCs to
IETF RFC 2119. S. Bradner. March 1997. Indicate Requirement Levels", BCP 14, RFC
http://www.ietf.org/rfc/rfc2119.txt. 2119, March 1997.
[Namespaces] Namespaces in XML, W3C Recommendation. eds. Tim Bray, [Namespaces] Namespaces in XML, W3C Recommendation. eds.
Dave Hollander, and Andrew Layman. http://www.w3.org/TR/REC-xml- Tim Bray, Dave Hollander, and Andrew Layman.
names/. http://www.w3.org/TR/REC-xml-names/
[NFC] TR15, Unicode Normalization Forms. M. Davis, M. Durst. Revision [NFC] TR15, Unicode Normalization Forms. M. Davis,
18: November 1999. M. Durst. Revision 18: November 1999.
http://www.unicode.org/unicode/reports/tr15/tr15-18.html. http://www.unicode.org/unicode/reports/tr15/
tr15-18.html.
[Unicode] The Unicode Standard, version 3.0. The Unicode Consortium. [NFC-Corrigendum] NFC-Corrigendum. The Unicode Consortium.
ISBN 0-201-61633-5. http://www.unicode.org/unicode/uni2errata/
http://www.unicode.org/unicode/standard/versions/Unicode3.0.html. Normalization_Corrigendum.html.
[UTF-16] UTF-16, an encoding of ISO 10646, IETF RFC 2781. P. Hoffman, [Unicode] The Unicode Standard, version 3.0. The Unicode
F. Yergeau. February 2000. http://www.ietf.org/rfc/rfc2781.txt. Consortium. ISBN 0-201-61633-5.
http://www.unicode.org/unicode/standard/
versions/Unicode3.0.html.
[UTF-8] UTF-8, a transformation format of ISO 10646, IETF RFC 2279. [UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an
F. Yergeau. January 1998. http://www.ietf.org/rfc/rfc2279.txt. encoding of ISO 10646", RFC 2781, February
2000.
[URI] Uniform Resource Identifiers (URI): Generic Syntax, IETF RFC [UTF-8] Yergeau, F., "UTF-8, a transformation format
2396. T. Berners-Lee, R. Fielding, L. Masinter. August 1998 of ISO 10646", RFC 2279, January 1998.
http://www.ietf.org/rfc/rfc2396.txt.
[XBase] XML Base ed. Jonathan Marsh. 07 June 2000. [URI] Berners-Lee, T., Fielding, R. and L. Masinter,
http://www.w3.org/TR/xmlbase/. "Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[XML] Extensible Markup Language (XML) 1.0 (Second Edition), W3C=20 [XBase] XML Base ed. Jonathan Marsh. 07 June 2000.
Recommendation. eds. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen http://www.w3.org/TR/xmlbase/.
and Eve Maler. 6 October 2000. http://www.w3.org/TR/REC-xml.
[XML DSig] XML-Signature Syntax and Processing, Joint IETF/W3C [XML] Extensible Markup Language (XML) 1.0 (Second
Working Draft. D. Eastlake, J. Reagle, D. Solo, M. Bartel, J. Edition), W3C=20 Recommendation. eds. Tim
Boyer, B. Fox, and E. Simon. July 2000. Bray, Jean Paoli, C. M. Sperberg-McQueen and
http://www.w3.org/TR/xmldsig-core/. Eve Maler. 6 October 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 Plenary Decision] W3C XML Plenary Decision on relative URI [XML Plenary Decision] W3C XML Plenary Decision on relative URI
References In namespace declarations, W3C Document. 11 September References In namespace declarations, W3C
2000. http://lists.w3.org/Archives/Public/xml- Document. 11 September 2000.
uri/2000Sep/0083.html. http://lists.w3.org/Archives/Public/xml-
uri/2000Sep/0083.html.
[XPath] XML Path Language (XPath) Version 1.0, , W3C Recommendation. [XPath] XML Path Language (XPath) Version 1.0, , W3C
eds. James Clark and Steven DeRose. 16 November 1999. Recommendation. eds. James Clark and Steven
http://www.w3.org/TR/1999/REC-xpath-19991116. DeRose. 16 November 1999.
http://www.w3.org/TR/1999/REC-xpath-19991116.
Author's Address Author's Address
John Boyer John Boyer
PureEdge Solutions Inc. PureEdge Solutions Inc.
tel: 1-888-517-2675 Phone: 1-888-517-2675
email: jboyer@PureEdge.com EMail: jboyer@PureEdge.com
Expiration and File Name Acknowledgements
This draft expires July 2001. The following people provided valuable feedback that improved the
quality of this specification:
Its file name is draft-ietf-xmldsig-canonical-01.txt. * 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
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
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.
 End of changes. 158 change blocks. 
536 lines changed or deleted 531 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/