FW: Transition strategies to xml:id

Forwarding from the XML CG list.  I suggest we do not
cc the CG, but feel free to cc Robin.

paul

-----Original Message-----
From: w3c-xml-cg-request@w3.org On Behalf Of Robin Berjon
Sent: Tuesday, 2006 January 24 19:25
To: XML CG
Subject: Transition strategies to xml:id


Dear XML CG,

being a good citizen in general, and a big fan of xml:id, the SVG WG  
decided to require it in its next specification, namely SVG Tiny 1.2.

The problem we have is that we already have an existing language  
that's been deployed for years, and therefore we need to support  
legacy content and legacy implementations. As you would expect, we  
already have an 'id' attribute that is available on practically all  
elements.

The only way in which we can devise a practical transition strategy  
is to support both id and xml:id in this version, and start  
deprecating id in future versions. In order to produce content that  
works in presently existing and deployed implementations as well as  
in future ones, the only workable strategy for content producers  
while the transition is being made is to have content that specifies  
both id and xml:id on relevant elements, with the same value (e.g.  
<rect id='foo' xml:id='foo'/>). Consequently, and after much  
discussion, this is what the current draft recommends.

We are aware that this causes problems with some validation  
technologies, but since our schema uses RelaxNG we are not affected  
by this issue. I believe that the specification was deliberately  
designed so that this would not be an issue, and so that our use case  
would be supported: "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." (end of  
section 4)

However we do run into problems with the following: "An xml:id  
processor should assure that the following constraint holds: The  
values of all attributes of type "ID" (which includes all xml:id  
attributes) within a document are unique." It's only a "should", so  
that we can specify that we have a good reason to violate this  
(otherwise there simply is no practical way for us to adopt xml:id).  
However "An xml:id error occurs for any xml:id attribute that does  
not satisfy the constraints" and later "A document is conformant to  
this specification if it generates no xml:id errors." Based on this  
it is unclear to us that we can specify conformant *content* that has  
two IDs with the same value on the same element.

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.
  b) we drop 'xml:id'. That's an option but to be honest it would  
really, well, be unpleasant. It's a small change but for a simple- 
minded Perl hacker like me xml:id has been the most useful addition  
to the XML stack since XSLT 1.0.
  c) we specify that you can't have both id and xml:id with the same  
value on the same element. This is impractical in the extreme: it  
means that you have to do two calls to getElementById to address  
processors from different versions, and you would need to duplicate  
every element that references IDs (and we have quite a few of those:  
all animations, use, all paint servers...). In effect this means that  
we might support xml:id, but no one will use it and we'll never be  
able to deprecate 'id' since people will just keep using it. Given  
this, there's no reason for us to add xml:id support, it just adds to  
the implementation burden without bringing any benefit.
  d) we unilaterally decide that we want to violate the xml:id Rec.  
This isn't optimal (to say the least), and we already have an LC  
comment to this effect.
  e) there is an erratum to xml:id that specifies that the uniqueness  
of the ID is per element and not per attribute. This is logical since  
it's the element's identity that needs be unique, not the  
attribute's. (The fact that some schema languages are opposed to  
elements having multiple identities is an orthogonal issue.)

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

There are several arguments in favour of considering this an error:

  - the fact that having a "native" id attribute and an xml:id  
attribute with the same value on the same element is not completely  
clearly defined as being an error
  - xml:id intends to replace former native id attributes. Without  
making it possible to have a transition strategy, it makes it very  
difficult for languages already largely deployed to adopt it
  - the problem does not apply only to SVG - I would expect XHTML,  
VoiceXML, MathML, etc. to suffer from the same problem
  - 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.

Thoughts? Comments?

(NB: I'm writing as the SVG WG participant in charge of this issue,  
don't blame Chris or EXI for anything you might disagree with :)

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

Received on Wednesday, 25 January 2006 19:29:33 UTC