RE: *Major* problem with xml:id in canonical XML

I'm not sure what I think just yet, but one thing to
point out is that no one can be using xml:id at this
time since all names starting with "xml:" are reserved.

I understand there are legacy implementations of the 
canonicalization code that might do the wrong thing if 
they came across xml:id, but there can't be any legacy 
documents out there using xml:id. 

In a sense, existing canonicalization code doesn't 
recognize xml:id because to date it didn't exist.

The canonicalization spec--and implementations based
on it--will have to be revised to support xml:id, and
when they are so revised, they'll have to support xml:id
properly.

In the interim, people using existing canonicalization
code that hasn't been revised to support xml:id might
get reasonable results or might not, but that's just
what happens when your tool set is part new (with xml:id
awareness) and part old (pre-xml:id existence).  While
it might have been better design for canonicalization
to have different default behavior for use of names in
the xml namespace, no single default can always solve 
the problem of doing the right thing with an element 
that doesn't yet exist.

paul

> -----Original Message-----
> From: public-xml-id-request@w3.org 
> [mailto:public-xml-id-request@w3.org] On Behalf Of Elliotte Harold
> Sent: Monday, 24 January, 2005 14:01
> To: public-xml-id@w3.org
> Subject: Re: *Major* problem with xml:id in canonical XML
> 
> 
> Daniel Veillard wrote:
> 
> 
> >   IMHO this should be raised as a bug in XML Canonicalization v 1.0
> 
> I'd call it a design flaw. At this point in time, I'm not sure we can 
> get away with calling it a bug and issuing an erratum. 
> There's a lot of 
> software out there that depends on the correct, spec compliant 
> functioning of canonicalization, and the stack is growing monthly. I 
> wouldn't want to guess how many other specs and systems would 
> fall over 
> if we pulled the this out from under them. The whole point of 
> canonicalization is that you get guaranteed, byte-per-byte 
> reproducibility, and changing even one bit breaks it all.
> 
> On further thought, I think the best we can do is recommend 
> that people 
> use exclusive XML canonicalization, and just live with 
> multiple IDs if 
> they use the regular form. XML Digital signatures allows alternative 
> canonicalizations, and XML encryption requires exclusive XML 
> canonicalization to be supported.
> 
> Longer term perhaps we should to define a new 
> canonicalization algorithm 
> that does inherit namespace mappings, xml:base, xml:space, 
> and xml:lang 
> (unlike exclusive XML canonicalization) but does not inherit xml:id. 
> This would of course have different identifying URIs for use in 
> signature and encryption. We only run into trouble if we 
> redefine what 
> http://www.w3.org/TR/2001/REC-xml-c14n-20010315 and 
> http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments mean.
> 
> -- 
> Elliotte Rusty Harold  elharo@metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/
> ref=nosim
> 
>

Received on Monday, 24 January 2005 20:41:34 UTC