Re: Schema Centric Canonicalization algorithm

[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