Canonical XML Version 1.0 Last Call Comments
This page links to comments/issues raised on the XML Signature list during (and after) the Last Call. This page also describes how these issues were resolved.
| Originator | Issue | Resolution |
| Doug Bunting Doug@ariba.com cXML Standards Manager, Ariba, Inc. |
In Section 2, the paragraph reading "An element has attribute nodes to represent the non-namespace attribute declarations appearing in its start tag as well as nodes to represent default attributes that were not specified and not declared as #implied." implies the legality of an attribute declaration such as <!ATTLIST form method CDATA #IMPLIED "POST">. This is not legal according to section 3.3.2 of the XML Recommendation. "Default attributes" must be either declared as #FIXED or simply with an attribute value. [Bunting-1]. | In [C14N-DataModel], the text is changed to the description you suggest in [Bunting-2]. Also, the other editorial tweaks given in [Bunting-1] have been addressed in [C14N-20000907] (the typo in the status section was corrected, the theorem/proof style was replaced by prose, the UTF-8 encoding was clarified, the required and recommended status of canonical forms without comments and with comments was specified, and numerous examples were added to clarify entity replacement as well as all other types of changes that C14N can make). |
| TAMURA Kent kent@trl.ibm.co.jp Tokyo Research Laboratory, IBM |
It needs to be made clear that UTF-8 encoding is without a byte order mark. [Tamura] [Martin-1] | This is now addressed in [C14N-DataModel] based on the discussion in Section 3.2 of [UTF-16]. |
| MURATA Makoto muraw3c@attglobal.net International University of Japan, Research Institute |
Need to preserver the XML declaration, or at least the version number within it. [Murata] [Martin-1] [Cowan-Version-2] | Firstly, focus should be restricted to version, since maintaining encoding and standalone status may be quite incorrect. Secondly, the absence of version unambiguously identifies the canonical form as version 1.0. The purpose of this specification is to canonicalize XML 1.0, not future versions of XML. Hopefully few modifications will be required to support a future version of XML, but I expect that a change to XML that affects XML processors should percolate through InfoSet to XPath and finally to C14N, at which point the XML declaration should be available (which it currently is not). See prior acceptance of this decision [Cowan-Version-1]. |
| Anli Shundi anli.shundi@nue.et-inf.uni-siegen.de Institute for Data Communications Systems, University of Siegen |
The new c14n drafts since June 1st have no samples at all unlike the previous ones. I think clarification samples are needed. I hope this won't pose any delays in the publication track. [Shundi] | Added comprehensive set. See [C14N-Examples] |
| Susan Lesch lesch@w3.org W3C |
Is "Canonical" a proper noun? It is lowercase in "canonical form" and uppercase in "Canonical XML." I would make it lowercase globally, except when referring to the title of this spec. [Lesch] |
|
| Susan Lesch lesch@w3.org W3C |
"REQUIRED" and "MUST" seem to be used in the RFC 2119 sense. You might say so, and add http://www.ietf.org/rfc/rfc2119.txt to References. [Lesch] | Done. [C14NTerms] [C14NRefs] |
| Susan Lesch lesch@w3.org W3C |
Below, a clause and paragraph number are followed by a quote and then
a suggestion. Comments are in brackets [].
|
All good. See [C14N-20000907]. Note that the theorems and proofs were replaced by prose now that they are better accepted. |
| Susan Lesch lesch@w3.org W3C |
XML-related recommendations, working drafts XML-related Recommendations, Working Drafts | Didn't change this because I am not talking about a specific recommendation or working draft. My current understanding is that these should be capitalized in titles. |
| Martin J. Dürst duerst@w3.org W3C |
These issues are I18N feedback from [Martin-1].
|
The first and second points are addressed separately above. The third point I did not address because it seems obvious that implementers will have to be careful to correctly implement their programs. Anyone who actually has this problem should be diligent enough to make themselves sufficiently well-informed before writing code. The fourth point has been corrected. I use 'UTF-8 encoding' but not 'a UTF-8 encoding' in [C14N-20000907]. On the fifth point, I changed 'recommended' to 'is working on'. The sixth point was addressed, including a reference to a good example by Cowan [Cowan-Example]. On the seventh point, note that the modification was made most specifically to address xml:lang, however it seemed prudent to apply the propagation to all xml attributes, including those not yet defined. |
| Martin J. Dürst duerst@w3.org W3C |
These issues are feedback from [Martin-2].
|
|
| John Boyer jboyer@PureEdge.com PureEdge Solutions Inc. |
PIs don't seem to need special encoding rule for #xD because it can never occur in PI data (entities aren't allowed in PI data). | Fixed. |
| John Boyer jboyer@PureEdge.com PureEdge Solutions Inc. |
It is necessary to change the input specification in order to sync up with transform processing model changes in the digital signature specification. | Fixed. The result is more generally applicable to other future uses of C14N. C14N should not evaluate a document subsetting expression; it should let the calling application do so, then pass the resultant node-set to C14N (ensuring that C14N's requirements of a node-set are observed). |
| Petteri Stenius Petteri.Stenius@done360.com Done Information, Ltd. |
Can anything be done about insignificant whitespace? [Stenius] | Although whitespace normalization can be quite important, it is often too application-specific. However, most of the whitespace that would be deemed insignificant in all applications can be eliminated by sending as input an XPath node-set in which all whitespace-only text nodes have been removed, e.g. using the expression 'not(self::text()[normalize-space()=""])' on every node. The expression can also be enhanced by looking for xml:space='preserve' in ancestors of such text nodes. Our reasoning against adding this into the core C14N algorithm is that is difficult to capture all of the variations and also difficult to get most tools to provide enough information to do a good job of this. [Tamura-2] |
| Lauren Wood lauren@sqwest.bc.ca |
Soften language in Section of 4.4 in [C14N-20000907] which claims that the Namespaces spec is incorrect in asserting that namespace prefixes have no information value. [Wood] | It is true that Namespaces came out before the other W3C recommendations (e.g. XPath and XSLT) that reference namespace prefixes. So, language has been changed to "there now exist a number of contexts in which namespace prefixes can impart information value in an XML document." [C14N-20001011]. |
| Doug Bunting Doug@ariba.com cXML Standards Manager, Ariba, Inc. |
In Section 2.1 of [C14N-20000907], clarify that turning the comment flag on doesn't result in retention of comments from the DTD. Also, the meaning of lexicographic order should be clarified as ascending order, and in the processing of comment children of the root node in Section 2.3, it should be made clear that 'root node' means the node above the document element [Bunting-3]. | To Section 2.1, I added the following "Note that the XPath data model does not create comment nodes for comments appearing within the document type declaration (DTD)." I added comments about lexicographic meaning ascending order, both at the end of Section 2.2 and directly in the processing statements in Section 2.3. Finally, I added text to the 'root node' processing as well as to the comment node processing in Section 2.3 to ensure that it is known that 'root node' means the parent of the top-level document element and that comment children of the root are outside of the top-level document element (and the document type declaration). |
| Gregor Karlinger gregor.karlinger@iaik.at IAIK TU Graz |
In [C14N-20000907], the example in section 3.6 needs a version number in the input document [Karlinger-1], and the example in section 3.4 needs to be corrected by removing the leading and trailing whitespace from the id attribute in the normId element. Also, the example is incorrect because it violates a validity constraint [Karlinger-2]. | Fixed example 3.6 and the whitespace in example 3.4. The validity constraint was intentionally violated, so I left it in, but made it clearer that it was there, and I also added another item that demonstrates the other issues demonstrated by that line using a valid attribute [C14N-20001011]. |
| Merlin Hughes merlin@baltimore.ie Baltimore Technologies, plc |
In the example of section 3.5 of [C14N-20000907], the NOTATION needs a SYSTEM, and the example in 3.7 should not have an xmlns="" in element E3. As well, condition 2 for including xmlns="" appears to be redundant with condition 3.[Hughes]. | Added SYSTEM in NOTATION of example 3.5. Corrected error in example 3.7 as follows: element e1 was supposed to be surrounding e2. Modified XPath expression to properly include e1 and exclude e2 despite the fact that e1 is now the parent of e2. Removed condition 2, which was redundant, and replaced it with a phrase in the prose that clarified that xmlns="" would not appear in [C14N-20001011]. |
| Susan Lesch lesch@w3.org W3C |
Typos and clarifications identified in [Lesch-2]. | Made changes exactly as suggested with two exceptions. First, the occurrence of 'xml namespace' was not changed to capital XML, but rather I put a code tag around the xml. Second, example 3.3 was not changed to use example.org because there is no technical fault in the example, so it did not seem prudent to throw off implementation tests at this time. |
| Kevin Regan kevinr@valicert.com ValiCert |
Many people will not get what they expect because c14n does not eliminate insignificant whitespace. [Regan] | This is a good point, but it has been considered numerous times in the past by the group, and interoperability with non-validating processors as well as correct operation in the absence of the DTD have been given as reasons for retaining insignificant whitespace, though applications are free to strip it before applying a signature, for example. For the final decision, please see [Reagle]. |
| Gregor Karlinger gregor.karlinger@iaik.at IAIK TU Graz |
Examples 3.4 and 3.7 use attributes of type ID. The examples do not have all DTD declarations necessary to be processable by a validating parser, yet the ID attributes seem to require a validating processor. [Karlinger-3] | This was considered by the group and the decision was that the maker of the non-validating processor being used had a bug to fix in terms of not handling ID attributes properly. [Reagle] |
| Jeff Cochran JCochran@docutouch.com DocuTouch |
The conversion to UCS character domain should be done using Normalization Form C if converting from a non-UCS encoding. Currently, the document says 'if converting from a non-Unicode encoding.' There is a difference, specifically the character planes outside of the 17 planes representable by UTF-16. | Fixed with wording change provided by Martin J. Dürst [Martin-3] |
| Martin J. Dürst duerst@w3.org W3C |
On Example 3.6, there needs to be a much better note to make very clear that (different to the other examples), this example is not really intended to be XML and cannot be used directly in a test. It would also be advisable to provide an actual file that contains the real bytes, or to point to it if that's already around. [Martin-4] | The actual text for all examples are provided in the comments of the specification, which you can get at by using view source. As to the specific example, there is a note indicating the difference, and it is the only note of the example. |
| Jonathan Marsh jmarsh@microsoft.com Microsoft Corporation |
The method in Section 2.3 by which superfluous namespace declarations are omitted does not seem to match the following sentence from Section 4.6: "...omits a declaration if it determines that the immediate parent element in the canonical form has an equivalent declaration." [Marsh] | Added the words 'in scope' to the end of the sentence, as suggested by Karlinger [Karlinger-3] |