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

On Sat, Feb 12, 2005 at 04:58:49PM -0500, Elliotte Harold wrote:
> "id" stands for identifier. The value of this element is supposed to 
> uniquely identify not just any element, but a particular element. This 
> identification can be used in many contexts: XPath, XPointer, XSLT, DOM, 
>  all sorts of custom written programs, and more. I claim that any 
> process that, as an unintended side effect, moves IDs from one element 
> to a different element, is deeply flawed.

  I tried to follow those cases, gave 3 examples depending on how the
id is being propagated.

> The problem is simply that IDs can unexpectedly move from the element 
> they are intended for, to an element that they were not intended for. 
> This will cause applications to choose the wrong elements. How that 

  Not wrong. Thy may find an element instead of not finding one. If 
they find the wrong element, in general as I tried to show the xml:id layer
will raise an error. I asked for examples, so insted of "may", "can"
or "will" just put up such an example. C.f. the mail title I'm trying
to assess damage, not saying that I have a final view on the topic.
Again I'm also the maitainer of a toolbox with xml:id and c14n, my goal
is not to screw my users, but to find what are the risks and potential
solution !

> While we can call out the potential problems in the spec, and warn 
> people who use xml:id to only use exclusive canonicalization, I fear 
> that someone is going to be receiving documents they did not write that 
> use xml:id, and processing them with tool chains that have not been 
> updated. In other words, they may never have even looked at the xml:id 

  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.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Received on Sunday, 13 February 2005 01:32:17 UTC