Re: Options for dealing with IDs

On Thursday, January 9, 2003, 1:50:54 PM, Robin wrote:

RB> Chris Lilley wrote:
>> QNames in attribute content is toothpaste that is already out of the
>> tube and all over the sink. And it seems to be less of a problem in
>> practice than might have been thought.

RB> I wouldn't go that far. I admit that QNames-in-content is often the best/only 
RB> solution and are a necessary evil in some cases. I also think that if option 6 
RB> is picked, then it needs to be able to point to namespaced attributes. Reasons 
RB> for this are 1) it wouldn't be complete otherwise and 2) if the advantage of 6 
RB> over 4 is that it allows people to keep the names of their ID attributes with 
RB> minimal change, we need to cater for people that use namespaced attributes. 
RB> Otherwise, I don't see what 6 has over 4.

I agree that option 6 makes most sense if it uses a qname and can thus
be used to declare any attribute as an id, including one in a
namespace.

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.

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.

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?

RB> This causes an unfortunate mismatch because attribute names are
RB> not. So the following would not make id an ID attribute:

RB>    <foo xmlns='http://foo.org/' xml:idAttr='id' id='worm'/>

Yes it would.  xml:idAttr says that the unnamespaced attribute called
id is of type ID. And there is one right there, with the value 'worm'.
So the example you give would work as expected. The fact that there is
a default namespace on the element name does not affect the
un-namespaced attribute at all.


RB> The xml:idAttr here is {http://foo.org/}id,

No, to get that you would have to say

<foo xmlns='http://foo.org/' xmlns:a='http://foo.org/'
 xml:idAttr='a:id' a:id='worm'/>

or

<a:foo xmlns:a='http://foo.org/' xml:idAttr='a:id' a:id='worm'/>


RB> course, nothing keeps us from specifying xml:idAttr's content as 
RB> Attribute-QName-In-Attribute-Content

Not sure what you mean there.

RB> but that's adding yet another subtle and confusing thing for users
RB> to know about, and contradicts common practice from XLST, XML
RB> Schema, etc. wriggle, wriggle, squirm, wriggle.

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> This appears to me to add cost for little practical value.
RB> Devising a tiny SAX tool that can check for existing ID attributes
RB> and switch them to xml:id seems to me to be a lot simpler than
RB> jumping through option 6's hoops.

I agree that the conversion is trivial for those who would wish to
make the change. I was trying to exhaustively list all the options,
including ones that did not require content to have its ID attributes
renamed.



-- 
 Chris                            mailto:chris@w3.org

Received on Friday, 10 January 2003 09:56:10 UTC