Re: Transition strategies to xml:id

Hi Norm,

On Jan 31, 2006, at 06:18, Norman Walsh wrote:
> | So the options I can see are:
> |
> |   a) we drop 'id' and decide that 1.1 content does not work in 1.2
> | processors. This is unacceptable.
>
> Is it? I don't see why 1.1 content would not work in 1.2 processors? A
> processor that is aware of 1.2 can surely be aware of the fact that in
> 1.1 the attribute was named "id" and in 1.2 it's named "xml:id".

If we radically amputate 'id' from the 1.2 specification, 1.2  
processors will be required to ignore it -- and we can't state that  
the "id" attribute is no longer supported and at the same time  
describe how to handle it. If we describe how to handle it we're back  
to whether we allow people to have both or not. And if we allow only  
one of 'id' or 'xml:id' on a given element, people will just keep on  
using 'id' (since it would be compatible with both versions,  
regardless of whether the spec says it's the "right" thing to do),  
which would foil our plans to get xml:id in post for world domination.

> I would have thought the problem was in sending 1.2 content to 1.1
> processors. Is that expected to work?

The problem is bi-directional. It must be possible for a 1.2 UA to  
understand 1.1 content, and it must be possible for an author to  
create 1.2 content that works in 1.1 UA (if perhaps through graceful  
degradation). So yes, it is expected to work, and that requires the  
ability to have the 'id' attribute in 1.2 content.

> | As you can see from the above, the only solutions are (b) or (e).  
> I'd
> | really like to avoid (b), so I'd like XML Core to kindly consider  
> (e).
>
> I fear you've overlooked http://www.w3.org/TR/REC-xml/#one-id-per-el
> (though perhaps you're not using DTDs so the whole notion of XML  
> "validity"
> is irrelevant).

No, I am aware of that part. There is no DTD for SVG 1.2 and the SVG  
WG reckons that if you're going to use DTDs to validate SVG content  
you're going to get a bunch both of false positives and of false  
negatives, so the one-id-per-el is just an extra false negative if it  
shows up. In fact the only feature that DTDs brought to SVG 1.1 was  
ID typing, and we'll be glad to not need that if we can indeed adopt  
xml:id.

> If the rest of the WG is content that (e) is possible and practical, I
> won't stand in the way. My concern is that it will make xml:id
> somewhat different from XML with respect to the constraint and I think
> we wanted to avoid that. OTOH, if you aren't using a DTD, there's
> little practical difference between uniqueness per attribute and per
> element.

Well, to be honest we're already somewhat different from XML that way  
in that we're using namespaces :-) (and then we also support XML  
1.1). Seriously though, is there a way that this could be supported  
with the same caveats as are outlined concerning having more than one  
attribute of type ID? Given that xml:id is already somewhat different  
from XML in that respect, the delta doesn't seem too hard to cross.

Perhaps that historical enlightenment on this limitation would help  
us make the right decision? Isn't this a restriction that was  
introduced for compatibility with SGML?

The SVG WG is willing to provide editorial resources if it helps.

> At first glance, however, I think I prefer (d). Maybe you can finesse
> this by saying something along the following lines.
>
>   During the transition period, while "id" is being phased out in
>   favor of "xml:id", many documents will not be entirely conformant to
>   the xml:id Recommendation nor valid with respect to the ID
>   uniqueness constraints of XML[1]. In time, when all significant SVG
>   software has been updated to support xml:id, the use of attributes
>   named "id" can abandonned and conforming documents will be
>   generated.
>
>   [1] http://www.w3.org/TR/REC-xml/#one-id-per-el

Ick. If the XML Core WG really prefers this option, sees no better  
way, and has convincing arguments enough that we can get out of Last  
Call with this we'll comply, but it's really not a preferred option.  
There is any number of other specifications that will have to go  
through this process, it would be nice if the transition could happen  
more elegantly.

> |   - the problem does not apply only to SVG - I would expect XHTML,
> | VoiceXML, MathML, etc. to suffer from the same problem
>
> Yes. FWIW, DocBook has addressed this problem by saying the attribute
> is named "id" in DocBook V4.x and "xml:id" in V5.x and the transition
> strategy is to cross that particular chasm in one step :-)

*sigh* I wish we could have it that easy :) I guess that most DocBook  
users when finding a document from a version they can't process will  
most often be happy upgrading their tools. We've got 100+ million  
mobile users (and unknown desktop numbers) to bump up, it's not going  
to work if we don't give content creators a way to address both 1.1  
and 1.2 UAs simultaneously.

> |   - the specification deliberately allows for multiple ID attributes
> | on a given element, allowing them also have the same value seems
> | logical and may actually have been what was intended.
>
> I think we intended to enforce the constraint that elements have one
> attribute of type ID.

I wasn't there when the spec was discussed of course, but if my spec  
exegesis is any good I think you in fact did intend to leave that  
constraint out since it is openly discussed and explicitly allowed in  
the specification: "Many validation technologies impose the  
constraint that an XML element can have at most one attribute of type  
ID. That constraint is /not/ imposed by xml:id processing."

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/

Received on Monday, 30 January 2006 23:11:14 UTC