- From: Chris Lilley <chris@w3.org>
- Date: Fri, 10 Jan 2003 20:14:52 +0100
- 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