- From: John Boyer <jboyer@PureEdge.com>
- Date: Fri, 2 Jun 2000 11:39:49 -0700
- To: "John Cowan" <jcowan@reutershealth.com>, <w3c-ietf-xmldsig@w3.org>
- Cc: "TAMURA Kent" <kent@trl.ibm.co.jp>
Hi John, The three issues you've raised are: 1) > encoding. Right. I forgot about that seeming hack in the XML spec. If all XML parsers were 'true' parsers, then there would be no need to escape ]]> from regular character content since it is not an expected token. Nonetheless, thanks for reminding me about this, and I will tweak the next c14n draft to put > encoding back in. 2) Comments. I apologize if I've offended you in some way, but since I haven't really corresponded with you before, I don't see how that is possible. W.R.T. javascript being in comments, they do appear to be in comments, and when I feed an XML compliant piece of HTML to an XML processor I have on hand, it does seem to report them as comments, so I don't believe I am 'calling the dog's tail a leg' so to speak. However, if you would prefer, I can remove the reference to javascript since the section a) points out other reasons for retaining comments b) easily shows how their elimination can be described. I seem to recall a SAX 1 technical write-up that claimed that SAX 1 would not send comment events because comments were for document authors, not document consumers. The assumption seemed to be that XML would only be authored in a text editor. If I am using a design tool, I don't want it to toss my comments. The point being that it is generally better to keep the comments, then give specific applications the ability to opt out. 3) Whitespace Text node descendants of the root. The toolsets' elimination of this whitespace would seem to be in contradiction of section 2.10 of the XML spec. However, the point is moot since the problem can be solved by the same idea as #2 above. The XPath expression to opt out of this is given. Therefore, if your particular XML processsor can't support their inclusion, then set up your application context such that it is clear that you are using something with behavior that is equivalent to the XPath expression provided. TAMURA-san, this should also solve your concern. By the way, is this a problem with your current implementation of XPath serialization as well? I am reticent to switch to automatic dumping of text node descendants of the root (and concomitant addition of a linefeed to each end of PI marker) because means each text node in the node-set must be checked for this condition, which reduces efficiency. Also, do the tools you have discard comments outside the main document element? In other words, do we have the same toolset problem with comment node descendants of the root? John Boyer Software Development Manager PureEdge Solutions Inc. (formerly UWI.Com) Creating Binding E-Commerce jboyer@PureEdge.com -----Original Message----- From: w3c-ietf-xmldsig-request@w3.org [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of John Cowan Sent: Thursday, June 01, 2000 8:25 AM To: w3c-ietf-xmldsig@w3.org Subject: Comment on Canonical XML draft of 2000-06-01, clause A.3 The reason for requiring ">" rather than simple ">" in previous drafts of Canonical XML is that the sequence "]]>" is not well-formed when used in character content. As written, the document <foo>]]></foo> will canonicalize as <foo>]]></foo> which is not well-formed. See XML Recommendation clause 2.4, third paragraph, last sentence, and note the modal verb "must". -- Schlingt dreifach einen Kreis um dies! || John Cowan <jcowan@reutershealth.com> Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer)
Received on Friday, 2 June 2000 14:40:07 UTC