Re: FW: Transition strategies to xml:id

I'll be on vacation this week and next when this is likely to be
discussed. Here are my first thoughts.

/ "Grosso, Paul" <pgrosso@ptc.com> was heard to say:
| 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.

I believe that's the case.

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

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

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

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

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.

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

| 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

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

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

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.