Working with Canonical XML
- Why Is Canonical XML Needed?
- Canonical XML Terminology
- Canonical XML Example: Different but Equal
- Summary
- For Further Exploration
This chapter is from the book
This chapter is from the book
This chapter is from the book
Since XML syntax permits a number of options (e.g., which form of empty elements to use, whether to use single or double quotes for attribute values, the order of attributes in a start tag, places where white space is considered insignificant, etc.), it is quite easy to create documents that are physically different and yet logically equivalent. The purpose of Canonical XML is to define an algorithm by which a particular physical representation of an XML document can be reliably and repeatedly reduced to its canonical (simplest) form. When the same algorithm is applied to physically different representations to produce their canonical forms, documents can be compared at this logical level.
Although it is true that two documents with the same canonical form are logically equivalent, it is not necessarily true that two documents that differ in canonical form must be logically different. This apparent contradiction makes sense when you consider that there are application-specific equivalences that might apply, such as when an RGB value is substituted for a color word, or an IP address is substituted for its fully qualified domain name, or even when a later version of a DTD employs different element or attribute names that are logically equivalent to their earlier counterparts. It's not possible for a general algorithm to account for such application-specifics, and therefore they are not within the scope of Canonical XML.
The Canonical XML Recommendation (http://www.w3.org/TR/xml-c14n) was published in March 2001. The initial Working Draft appeared in November 1999. Although you might think there would be a close correspondence with the XML Information Set, this is not the case. While the January 2000 Working Draft (http://www.w3.org/TR/2000/WD-xml-c14n-20000119.html) was explicitly based on the Working Draft of the Infoset at that time, it was ultimately decided to base canonicalization (sometimes abbreviated "c14n") on the XPath data model instead. See the "Resolutions" section of Canonical XML for details and rationale (http://www.w3.org/TR/xml-c14n#Resolutions).
Why Is Canonical XML Needed?
It is possible to produce multiple physical variations of the same logical document due to a number of aspects considered insignificant in terms of XML syntax and Namespaces in XML. Therefore, applications may change an XML document in ways that are logically insignificant yet still (in my opinion) annoying and inconvenient.
A common example is XML editors who insist on reformatting XML by adding or removing white space, changing indentation, changing quotation marks, and perhaps even changing the order of DTD declarations. Although Canonical XML does not address these annoying differences, it can be used to verify whether an application that processes XML has changed the information by comparing the canonical form of the original input to the canonical form of the processed document. In other words, these editors may muck quite freely with the optional aspects of XML, but they certainly must not change the information items; this can be verified with a Canonical XML processor.
Perhaps the most important application of Canonical XML is in terms of digital signatures to ensure that the information content has not changed since the document was digitally signed. The signature is initially generated using a digest calculation based on the canonical form of the document. After its transmission, the receiving application applies the same algorithm to the document, producing another digest of the canonical form, and the two digests are compared. If they differ, it means the canonical forms differ, so the document must have been altered since signature.
In fact, Canonical XML was originally under the purview of the XML Core Working Group (http://www.w3.org/XML/Activity#core-wg), which also developed the Infoset, XML Inclusions, and XML Fragment Interchange specifications. Work was transferred midstream to the joint IETF/W3C XML Signature Working Group (http://www.w3.org/Signature/) in early 2000.