W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > February 2005

Re: Trying to assess the depth of xml:id and c14n incompatibilities

From: Elliotte Harold <elharo@metalab.unc.edu>
Date: Sat, 12 Feb 2005 20:53:26 -0500
Message-ID: <420EB316.4030805@metalab.unc.edu>
To: veillard@redhat.com
CC: www-tag@w3.org, public-xml-core-wg@w3.org, public-xml-id@w3.org

Daniel Veillard wrote:


>   then xml:id will not pollute their IDs and they won't find the wrong id
> or they will in general get an error at the xml:id level.

I don't think I expressed myself clearly enough. Consider this: a team 
is using tools they themselves did not write. In particular they are not 
the sort of people who hang out on xml-dev and hears about problems like 
this. They are just trying to get their work done. They are using:

1. A standard C14N software that treats xml:id as the spec currently 
requires.

2. A processor that recognizes xml:id as an ID.

3. A document sent them by somebody else that uses xml:id

Their IDs can start moving for no reason that's apparent to them.

Even worse: suppose someone sends them a document that uses xml:id along 
with a DTD (possibly internal) or schema that specifies that the type of 
xml:id is ID, as is indeed recommended in the xml:id CR. Now they don't 
even need to be using software that treats xml:id as special in any way. 
They could have a tool chain and process in place *today* that is going 
to fail the first time someone sends them such a document.

I don't know who it's going to happen to. I don't know how many people 
this is going to affect. I suspect most people it does affect will not 
be affected too greatly; but I do think it's going to happen, and 
because we're mucking with security infrastructure here , it's possible 
somebody is going to get hurt badly.

Given that the problem exists with today's software that fully conforms 
to the specs, the only thing we can effectively change to prevent this 
is the one piece that isn't released yet. That's xml:id.

Longer term, I do agree that it's time to deprecate canonical XML and 
start moving the world to exclusive canonicalization or an alternate, 
new algorithm that inherits xml:space, xml:lang, and namespaces declared 
but not anything else (Semi-exclusive canonical XML?) but that's not 
going to happen soon enough to rescue the current xml:id scheme. Even if 
we could get a spec out quickly, it will take years to shift the 
installed base and all the dependent specs.

-- 
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 Sunday, 13 February 2005 01:53:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:32 GMT