Re: XML Signature use of Canonical XML

At 02:54 PM 4/10/00 +0900, Martin J. Duerst wrote:
>It's not the algorithm for finding URIs for plain
>Element or Attribute qnames that is difficult. In that
>case, what's a qname is very well defined and very
>easily identified, and how to find the corresponding URI
>is equally well defined.
>
>But that's not what I'm taking about. It's the use of
>qnames in attribute values, in XPath, and so on, which
>is frightening me. In these cases, what is a qname is
>not at all globally defined, you need additional knowledge.
>Also, how to find the relevant URI may depend on a lot of
>things inside and outside the attribute. And almost every
>spec that tries to use qnames invents another way to find
>the URI. All of this is done with a side glance to the
>Namespace spec, but is not at all based on the Namespace
>spec. So my claim is that Qnames don't easily scale to wider
>use than Element/Attribute names.

I recently made a posting on the Linking IG list that analyzed exactly this 
concern, related to XLink's use of QNames in attribute values on the role 
and behavior attributes.  I've reproduced most of it below.  (The original 
post was at 
http://lists.w3.org/Archives/Member/w3c-xml-linking-ig/2000Apr/0025.html.)

                         *               *               *

The reason that I'd like to avoid QNames in attribute values is that it 
raises a number of questions whose answers our group has no charter to
decide.

It's pretty clear that the Namespace spec (non-normative Section A.2, 
http://www.w3.org/TR/REC-xml-names/#ns-breakdown) suggests the following 
"partitions" of a namespace (syntax made up by me):

   {NS}GI                (element name unique throughout the NS)
   {NS}att               (attribute name unique throughout the NS)
   {NS}{GI}att           (attribute name unique for a certain GI)

The use of QNames in attribute values in the XML Schema and XSLT specs is 
confined (mostly? or all?) to references to these sorts of names.  They 
would still have canonicalization problems because their prefixes wouldn't 
get normalized, but at least they're not inventing new partitions in these 
cases.

Our use of QNames in the value of the role attribute conforms to something 
like this partition, I think:

   {NS}attval            (attribute value -- or generalized and call it
                          a token? -- unique throughout the NS)

But I think our use of QNames in the value of the behavior attributes is 
something like this (because all of XLink's attributes are global, and 
because I'm not sure we intend to disallow "xlink:new" as the value some 
other attribute that we might add later, such as 
xlink:disallowTheseBehaviors :-):

   {NS}{att}attval       (attribute value unique for a certain global
                          attribute)

And that suggests yet another possibility (though this starts smelling more 
and more like a regular set of enumerated values set up in a DTD or schema):

   {NS}{GI}{att}attval   (attribute value unique for a certain attribute
                          on a certain element)


I just don't want to go here in advance of its being sorted out in the 
Namespaces spec, even if other specs have started in this direction.  It's 
quite possible that XLink and the other specs already clash on these 
matters in some respect anyway, which is exactly the danger of using 
something that hasn't been standardized.


Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center    elm @ east.sun.com

Received on Monday, 10 April 2000 11:06:53 UTC