- From: Joseph Reagle <reagle@mit.edu>
- Date: Thu, 14 Mar 2002 15:59:58 -0500
- To: "Bob Atkinson" <bobatk@Exchange.Microsoft.com>, <reagle@w3.org>
- Cc: <uddi-security@yahoogroups.com>, <w3c-ietf-xmldsig@w3.org>, <jboyer@PureEdge.com>, <selim.aissi@intel.com>, <mhondo@us.ibm.com>, "Allen Brown" <allenbr@microsoft.com>, "Ashok Malhotra" <ashokma@microsoft.com>
[We've had discussion on the "esoteric nodeset" [1], just wanted to finish off a couple of the other threads. [1]http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0209.html ] On Tuesday 12 March 2002 17:38, Bob Atkinson wrote: > Regarding the comment about exc-c14n and the default XML namespace > prefix: I am glad to hear that this was rectified in the CR; we will > update SCC14N accordingly in our next available draft. Ok. > one can usually design reasonable relational > tables that straightforwardly mirror the semantic content of the data > being communicated, and write shredding and reconstitution code to handle > the translation. However, the additional burden imposed here if one is > further required to preserve actual namespace prefixes used is large and > significant: ns declarations can exist on each and every element, perhaps > with many and several declarations for the same prefix, scoped according > to the elemental hierarchy. Recording this in the relational store is > relatively hard and difficult, and is often in tension > relational-schema-wise with the attempt to model the semantics of the > data in question. Thank you, I understand. > Regarding [normalized value]: If I understand correctly, there seems to > be no actual issue here for us with respect to SCC14N. Moreover, I am > greatly confused as to the confusion. Ok, with your assurance and a quick re-review of the Schema spec I'd agree that schema shouldn't touch the infoset items at all, just the schema augmented items. (If XSV did this, then I presume it was in error.) > Regarding CDATA: I would agree that the information models of Infoset, > XPath (ie: node set), and (apparently) DOM are different, that at times > this causes difficulties for some, and that this is regrettable. However, > the particular CDATA issue noted doesn't arise in the node set to Infoset > conversion that we must in SCC14N undertake (due to the XML DSIG > transformation requirements), and SCC14N being internally completely > Infoset based also has no internal such conversion problems. That dealing > with the DOM brings these issues to the fore is regrettable, but in the > end personally I think simply reflects on the pragmatic utility of the > DOM API to applications. Ok. > Regarding Canonicalizing URIs: Your text and reference are intriguing. > We'll take another look as to whether it seems worthwhile for us to > reconsider our present no-action thoughts. I don't want to be misunderstood: I'm not protesting your inaction. I feel that if anyone comes up with an approach, I'd like to see it as a small, separate spec that is vetted by the larger community.
Received on Thursday, 14 March 2002 16:00:16 UTC