RE: Comment about C14N last draft

• From: John Cowan <cowan@locke.ccil.org>
• Date: Tue, 6 Jun 2000 19:02:37 -0400 (EDT)
• To: John Boyer <jboyer@PureEdge.com>
• cc: David Blondeau <blondeau@intalio.com>, "Joseph M. Reagle Jr." <reagle@w3.org>, w3c-ietf-xmldsig@w3.org, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
• Message-ID: <Pine.BSI.3.95.1000606190002.27358A-100000@locke.ccil.org>

On Tue, 6 Jun 2000, John Boyer wrote:
>  This seems like a good idea since we really don't know what's coming
> in future versions of XML, so deciding how to canonicalize it now may not be
> appropriate.  For example, it could happen that neither infoset nor xpath
> have a data model that adequately captures the next version of XML.
I think this is exactly right.
> However, even if you want to preserve the XML version, the fact that c14n
> applies an xml processor to the input to produce a node-set does not change
> the fact that c14n *has* the input and can therefore recover the version,
> although an application function hook may be required to help with character
> encoding issues for non-UTF.  Also, the absense of a version should be
> construed as 1.0.
I don't think it's appropriate to plan a processing model for non-1.0
XML; we don't have any idea what parsers for it will look like, or
what styles of APIs they might expose.  Define Canonical XML for
XML 1.0 only, and generate a fixed XML declaration.
When XML is updated, time enough to update Canonical XML too.
> B) use a version of 1.0
Check.
-- 
John Cowan                                   cowan@ccil.org
	"You need a change: try Canada"  "You need a change: try China"
		--fortune cookies opened by a couple that I know

Received on Tuesday, 6 June 2000 18:44:45 UTC