Re: Options for dealing with IDs

Chris Lilley wrote:
> On Thursday, January 9, 2003, 1:50:54 PM, Robin wrote:
> RB> One issue with QNames in content stems from the fact that prefixes are not 
> RB> usually considered to be first-class information.
> 
> Well, thats because prefixes are *not* first class information.
> Certain well-deployed historical parsers aside, the prefix used is
> irrelevant.

I know, which is precisely the problem at hand.

> RB> They can thus be rewritten, which in turn would cause one to lose
> RB> QICs unless typing is involved. I've hit that wall myself.
> 
> No, it would not. I was careful, when describing that option, to note
> that a qname in an xml:idAttr value would immediately be  reolved to a
> URI, local name pair. So for example
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <foo xmlns="URIone" xmlns:a="URItwo" xml:idAttr="a:pling">
>         <toto a:pling="x1"/>
>         <b:tata xmlns:b="URItwo" xmlns:a="URIthree" a:pling="x2"/>
>         <a:titi pling="x3"/>
> </foo>
> 
> Would make the attribute on toto an ID, and not the ones on tata and
> titi. Any amount of rewriting anywhere in the tree would not affect
> that.

Slurping the above document into a representation that throws away prefixes (as 
it very well can) and reserialising it could yield:

  <?xml version="1.0" encoding="UTF-8"?>
  <ns1:foo xmlns:ns1="URIone" xmlns:ns2="URItwo" xml:idAttr="a:pling">
          <ns1:toto ns2:pling="x1"/>
          <ns2:tata xmlns:ns3="URIthree" ns3:pling="x2"/>
          <ns2:titi pling="x3"/>
  </ns1:foo>

The "a" prefix in xml:idAttr doesn't map to any declared namespace anymore, and 
thus the toto element ceases to have an ID attribute. In other words, the lack 
of importance of prefixes means that all applications in the processing pipeline 
have to know about xml:idAttr. In previous installments of the same problem, 
I've sometimes had to end up keeping prefixes around which is unpleasant because 
I shouldn't need to.


> RB> Another issue is that they are normally (in all cases I've seen them used in at 
> RB> least) sensitive to the default namespace.
> 
> Sensitive in that they can't use it?
> (snip) 
> The fact that there is
> a default namespace on the element name does not affect the
> un-namespaced attribute at all.
> (snip)
> I hope that the common practice that you are thinking of isn't what it
> seems to be, because then it would be wrong.

So do I, but the common practice seems to be more muddied than I was innocently 
thinking it were. I thought that default namespaces *always* applied to QNames 
in content. It turns out that the XSLT trouble I'd had was a now fixed 
implementation bug. From the XSLT spec:

     2.4 Qualified Names
     The default namespace is /not/ used for unprefixed names.

However, XML Schema seems (if I'm making out the language correctly) to think 
otherwise (notably point 2.2.1 there):

     3.15.3 Constraints on XML Representations of Schemas
     The appropriate case among the following must be true:
     1 If its ˇnormalized valueˇ is prefixed, then all of the following must be
       true:
       ...
     2 otherwise (its ˇnormalized valueˇ is unprefixed) all of the following must
       be true:
       2.1 its ˇlocal nameˇ is its ˇnormalized valueˇ.
       2.2 The appropriate case among the following must be true:
         2.2.1 If there is a namespace in the [in-scope namespaces] whose
               [prefix] has no value, then its ˇnamespace nameˇ is the [namespace
               name] of that namespace.
         2.2.2 otherwise its ˇnamespace nameˇ is ˇabsentˇ.

This certainly seems to fit with the behaviour of XML Schema processors I've 
seen. It also matches the behaviour of some other specs I've seen that used XML 
Schema.

So it looks like we have a small mess already in that area, with conflicting 
common practices. However the fact that contrary to what I thought not applying 
the default namespace to QICs is already there (and in the sanest of the listed 
specs) this nullifies my argument about xml:idAttr introducing a special case.

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Friday, 10 January 2003 13:21:18 UTC