Bulk edit of New public comments with no find or fix assignments and which start with "Re:" to Noise component, assigned to Rob for review.

We should make sure we resolve this one way or another in ODF 1.2 and be prepared to defend our choice. In particular, I wonder what would be the result if we tool Murata-san's suggestion here?

Some background reading of the issue can be found at:

http://blog.jclark.com/2009/01/relax-ng-and-xmlid.html

James Clark is one of the co-authors of the RNG DTD Compatibility specification. The other is Murata-san.

In the current ODF 1.2 specification we have a normative reference to the xml:id specification. We have no reference to the RNG Compatibility specification.

If we follow James Clark's recommendation, then, if I haven't overlooked anything, we define xml:id attributes of type ID. This would be in alignment with the (non-normative) recommendation of the W3C xml-id specification, but it would not be in alignment with the (unreferenced) RNG DTD Compatibility specification.

If we follow Murata-san's suggestion, then we would define xml:id attributes of type NCName. This would be in alignment with the (unreferenced) RNG DTD Compatibility specification, but it would not be in alignment with the (non-normative) recommendation in xml-id specification. It would also cause errors in JING if James Clark changes jing as described in his blog.

So, it seems that we cannot get both, alignment with the recommendation of the xml-id specification and alignment with the RNG DTD Compatibility specification.

I have no strong opinion whether the one or the other option is technically "more correct" than the other. But I have a slight preference for the xml:id of type ID approach, simply because we do reference the xml-id specification but don't reference the RNG DTD Compatibility specification.

Other public comments related to the topic are:

http://lists.oasis-open.org/archives/office-comment/200805/msg00015.html
http://lists.oasis-open.org/archives/office-comment/200903/msg00081.html
(default values have been removed from the schema in the meantime)

I disagree that this is a trivial issue.

I am aligned with the notion that xml:id be defined to have type ID. That makes it valid for reference in fragment identifiers in IRIs, such as those used in RDFa and the RDF Metadata extension introduced in ODF 1.2. [xml-names] is not going away. Only the W3C gets to say what the rules are for use of xml:* forms of names and the implicit XML namespace they are bound to.

CAUTION: There is an important rule in [xml-names] that must be honored, however.

It is permissable for the same element to have multiple attributes (of different name) with type ID. However, they may not have the same values. In fact, duplicate values are not permissible for attributes of type ID anywhere in the same XML document, regardless of the name of the attribute.

This is an important matter where there are ODF 1.1-and-prior attributes that have been changed from type ID to type NCName. In particular, these are no longer referenceable via attributes of type IDREF. Instead, they can be reference by attributes of type NCName. It is appropriate to make this change since the defining occurrence is often in a different XML document of the same package (that is, it is a non-IRI reference from one package XML document to a fragment of another XML document in the same package and part of the ODF-specific structure).

The problem with the change to NCName is that all of the semantics regarding which occurrences are the defining occurence (akin to ID) and which are referencing occurrences (akin to IDREF) must be spelled out in the ODF specification and the rules for integrity of the structure must also be established. (I.e., whether a document is ODF-valid even when there are references not satisfied by defining occurrences, when there are duplicate defining occurrences, etc.)

In addition, there are uses of "name"-type attributes in this way but the attributes are specified to have values of type string. Reverting to NCName has much more conceptual integrity, but it it probably a breaking change and there may need to be a deprecation cycle to work our way out of that.

In some cases, it is not clear whether some naming-usage attributes that are part of the structural connection among XML documents of a package are meant to be user specifiable and are required to be user-presentable. The domain of uniqueness is also unclear in that regard. (For xml:id the domain of uniqueness is the XML document but that is insufficient for these names that are defined and referenced in different XML documents of a package. However, these could have distinct domains, such as table names versus chart names versus drawing names where uniqueness is only required to be preserved within such domains. It is very unclear what the requirement is for ODF and how users are to understand it when given the opportunity to choose the value of the name string.)

RECOMMENDATION FOR CONSIDERATION

It is these considerations that lead me to recommend that xml:id be the only attribute of type ID, ad that there be no attributes of type IDREF in the ODF structure itself. This would leave xml:id for establishing fragment identifiers that are used only via IRIs and could be used by RDFa and the RDF metadata and any other special purpose without concern for interfering with the ODF-required document structure. So long as an element is preserved in editing and other processing that leads to a derived document, any xml:id should be preserved.

I also believe that xml:id should be allowed on any element and that processors that rely on xml:id in some way will be able to sort out which ones matter for its processes and which ones are immaterial but will be preserved (so long as validity requirements of xml:id typing are maintained).

All attributes whose type was ID in ODF 1.1 have been deprecated in ODF 1.2 in favor of xml:id. In addition, some language has been added that they must not occur without an xml:id attribute and that their values must be in sync with the value of the xml:id attributes. This means, they are not defining any alternative IDs nor do they reference any other elements. They are only still allowed to provide backward compatibility with ODF 1.1. (In CD03 this language is missing for some attributes. That's OFFICE-1359). Further, xml:id is the only attribute of type ID in ODF 1.2.

Regarding IDREF: If we are not using IDREF in the schema, we are loosing the possibility that ID/IDREF integrity is checked. Given that we stay with using the type ID for xml:id, we are not having any advantage of this.

Allowing xml:id on any element is difficult because ODF implementations usually don't operate on the XML structure, but map that to an internal model, which does not have counterparts for all ODF elements. The list of elements that support xml:id has been chosen with that in mind.

Since no objections to define xml:id of type ID have been raised I'm marking this issue as resolved.

No further comments have been added. Marking the issue as "applied".