W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: Options for dealing with IDs

From: Chris Lilley <chris@w3.org>
Date: Fri, 10 Jan 2003 20:14:52 +0100
Message-ID: <154324076109.20030110201452@w3.org>
To: Robin Berjon <robin.berjon@expway.fr>
CC: www-tag@w3.org

On Friday, January 10, 2003, 7:20:42 PM, Robin wrote:

RB> Chris Lilley wrote:
>> 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.

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

It could if what the processor did was 'throw away or transform
prefixes on elements in a qname-in-attr-value insensitive way'

RB>   <?xml version="1.0" encoding="UTF-8"?>
RB>   <ns1:foo xmlns:ns1="URIone" xmlns:ns2="URItwo" xml:idAttr="a:pling">

Reserialisation error on line 2.  pling is in the URItwo namespace

RB>           <ns1:toto ns2:pling="x1"/>
RB>           <ns2:tata xmlns:ns3="URIthree" ns3:pling="x2"/>
RB>           <ns2:titi pling="x3"/>
RB>   </ns1:foo>

RB> The "a" prefix in xml:idAttr doesn't map to any declared namespace
RB> anymore,

Right; I would say that was the fault of whatever processor decided it
could assume that attribute values were never qnames.

RB> and thus the toto element ceases to have an ID attribute. In other
RB> words, the lack of importance of prefixes means that all
RB> applications in the processing pipeline have to know about
RB> xml:idAttr.

or any other attribute that takes a qname.

RB> In previous installments of the same problem, I've sometimes had
RB> to end up keeping prefixes around which is unpleasant because I
RB> shouldn't need to.

You don't need to keep the *same* prefixes around, but sometimes you
need to keep them on attribute values because there is no defaulting
of prefixes on attribute values.

>> 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.

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

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

Right (Jeni has already flagged that on this thread)

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

Yes (Jeni said that too; the latter was new to me)

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

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

RB> So it looks like we have a small mess already in that area,

I would agree. I was very surprised to hear, if I understand this
correctly correct, that W3C XML Schema contradicted what the
Namespaces in XML spec said about unprefixed attribute values where
namespaces had been defaulted on the element.

RB> with conflicting common practices. However the fact that contrary
RB> to what I thought not applying the default namespace to QICs is
RB> already there (and in the sanest of the listed specs) this
RB> nullifies my argument about xml:idAttr introducing a special case.

Okay. Now I guess you can ask the Schema folks what the reasoning was.

 Chris                            mailto:chris@w3.org
Received on Friday, 10 January 2003 14:14:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:56 UTC