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