I recommend that this analysis be double-checked carefully.
I believe there is a serious defect in the way xml:id is introduced in ODF 1.2 and in how other uses of attributes having ID type are being deprecated.
Because this is relevant to the way the ODF 1.2 Metadata proposal is introduced (and it is partly what led to this research), I believe this topic needs to be given urgent attention.
1. The problem is with the statements of this kind (here from 18.7 on anim:id):
The anim:id attribute assigns an ID to an animation element.
The anim:id attribute is deprecated in favor of xml:id. See 18.1278.
Applications that read documents shall ignore this attribute if
there is an xml:id attribute existing for the same element.
If no xml:id attribute is existing for the same element, then the
anim:id attribute should be processed as it were an xml:id attribute.
Applications that write documents may still write anim:id attributes
in addition to xml:id attributes. An element shall not have an anim:id
attribute if there is no xml:id attribute existing for the same element.
The value of the anim:id attribute shall equal the value of the xml:id
attribute.
There are several difficulties:
1.1 The proper rules for identifying XML elements as targets of fragment references (including via IDREF and IDREFS) has to do with the type of the attribute, not its name, whether or not the name is xml:id ( or has "id" in it, although there is a widespread practice of using attributes with "id" as their local name as names of ID valued attributes).
1.2 [XML 1.0] forbids (as valid XML) elements having more than one attribute of type ID and any two attributes of type ID having the same value in the same XML document (accessing fragments in a different XML document being a separate matter usually handled with a URI).
1.3 The [XML Names] specification preserves that rule but further constrains attributes of type ID to have values that are lexical NCNames rather than Names (that is, no ":" characters in the values for attributes of type ID).
1.4 The [xml:id 1.0] specification very carefully preserves the [XML 1.0] requirement. There is a place that can be read as relaxing the [XML 1.0] rule, but that is not about the validity of the document but about a requirement on processors.
1.5 The only language that I can find that proposes two attributes taking the same value, one of them being of type ID, is when the others are *not* of type ID. [This, by the way, is a better way to deprecate those ID-valued attributes from ODF 1.1 so that they don't clash with use of xml:id -- change them to have values of type NCName rather than ID in a way that ODF 1.1 usage remains upward compatible but there is no collision with an xml:id on the same element.] An example of such language is in [XHTML 1.0] section C8:
In XML, URI-references [RFC2396] that end with fragment identifiers
of the form "#foo" do not refer to elements with an attribute
name="foo"; rather, they refer to elements with an attribute defined
to be of type ID, e.g., the id attribute in HTML 4. Many existing
HTML clients don't support the use of ID-type attributes in this
way, so identical values may be supplied for both of these
attributes to ensure maximum forward and backward compatibility
(e.g., ...).
The suggested use of identical values depends on the fact that the name attribute is *not* of type ID and the id attribute is. (Also, notice that the discussion is about HTML clients, not XML processors.)
For reference, I have added the specific sources below. I believe this is situation is easily cured, but we need to align on the cure so that the ODF 1.2 draft and effected proposals can be adjusted and reconciled.
- Dennis
A. [XML 1.0] RULES
A.1. My source is
[XML 1.0] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau (eds.). Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, available at