W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2000

RE: Comment on Canonical XML draft of 2000-06-01, clause A.3

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) &gt; 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 &gt; 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

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

-----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 "&gt;" 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


will canonicalize as


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:33 UTC