Re: Typo in xml-id spec; canonicalization?

Elliotte Harold wrote: ...
> However regular inclusive XML canonicalization is also used in 
> signatures and it does have this problem.

Henry S. Thompson wrote:
> Exclusive canonicalisation has no negative interactions with xml:id 
> -- which gets used in your application domain?

We are drafting revisions to the GJXDM.  We have a wide variety of applications and patterns of usage to support, so breaking tools would not be a good thing.  

It seems that three of the major camps on this issue are:

  1. The canonicalization spec is broken, fix it

  2. The xml-id spec is broken, use 'xmlid' instead

  3. The xml namespace is static, use a different namespace instead.

I must admit to falling into camp 1.  It seems that the canonicalization spec was overbroad in its assumption that all attributes within the xml namespace would support this copying behavior.  It seems clear from the c14n spec that they do not expect the list of attributes in the xml namespace to be fixed:

     All element nodes along E's ancestor axis are examined for nearest
     occurrences of attributes in the xml namespace, such as xml:lang and
     xml:space ...

They assumed (correctly) that other attributes would be added to the namespace, but were wrong in believing that they would support copying.  An errata could be added to the canonicalization spec that clarified the point, and make explicit exactly which attributes from the xml namespace are merged in.

I do not like option 2 (xmlid), as it would require repeated redefinition of the attribute.  Each time a type wishes to use the attribute, it would have to redefine it locally.  We would prefer to see a single common definition, with uses of the attribute referring, instead of redefining.

Option 3 doesn't seem like it is a real option, as the only invariant namespace prefixes fixed by the XML Namespace standard are xmlns and xml.  To add another one for this problem seems a bit of a stretch.  It seems like c14n should take the hit.

In any case, what could we do to get past the stalemate on this issue?

Thanks,
Webb

-- 
Webb Roberts (webb.roberts@gtri.gatech.edu)
Research Scientist, Georgia Tech Research Institute
Atlanta, GA  404-385-0181

Received on Wednesday, 4 May 2005 15:55:34 UTC