Re: Options for dealing with IDs

Chris Lilley wrote:
> On Friday, January 10, 2003, 7:20:42 PM, Robin wrote:
> 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

Error only for processors supposed to understand xml:idAttr, but perfectly 
normal for others. That's precisely the issue I see here: all that software 
needs to be modified, upgraded, or at least checked to make sure that it will 
not remap prefixes.

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

A processor following XML + Namespaces has no reason to think otherwise. In 
order to work in a different fashion it needs to either a) consider prefixes 
first-class (or at least a bit higher than second-class), b) know about 
xml:idAttr, or c) have access to typing information telling it which attributes 
hold QNames.

Received on Wednesday, 15 January 2003 22:13:32 UTC