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

  Hi Tim :-)

On Sat, Feb 12, 2005 at 01:19:43PM -0500, Tim Berners-Lee wrote:
> 
> On Feb 12, 2005, at 11:02, Daniel Veillard wrote:
> >problem which may arise are:
> >   1/ layers implementing xml:id will raise an error, however this is
> >      not a fatal error (see http://www.w3.org/TR/xml-id/#errors)
> >      xml:id processors are just instructed to report the duplicate ID
> >      error to the application using it
> >   2/ XPath pointers to that fragment can be disrupted
> >
> 
> If you go down this path, then the xml:id spec could I suppose
> say that if there are >1 id of the same name then the outermost one
> is the relevant one, and that would even ensure the fragid reference
> still works

  Well, XPath say so already, and since XPointer reuse XPath id()
definition this is garanteed if you are using fragment identifiers.
Also xml:id should only change infoset informations for the xml:id
attributes, I don't see it changing attribute type for other attributes
of type ID, so we sould be limited only to the xml:id attributes.
  I think one big use case we need to consider when dealing with this
problem is a document made from a general enveloppe and signed part(s)
using Digital Signature and hence a Canonicalized fragment, then
the IDs may come from the enveloppe or from the fragment, and we can
get clashes there too, the clashes can be either from normal IDs
say in the enveloppe and from xml:id which may have been inherited 
from the original document(s) containing the fragment(s).

  Still I agree that making sure xml:id reports all ID clashes found
and the "first in document order wins" property of XPath id() should
really limit potential damages. But again I probably miss some
cornercases.

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 Saturday, 12 February 2005 19:14:29 UTC