I agree about xml:id being a public API in some cases. However, that is not how xml:id is profiled in ODF. ODF limits xml:id to very specific cases and does not consider its arbitrary use to establish anchors. It's also nothing [xml-id] specification requires. In fact, it strikes me that [xml-id] was not originally intended for that purpose.
If it was left to me, I would go the other direction:
1. xml:id would be allowed on any and all elements and it would be for fragment location. There would be *no* ODF-constrained use for it. Preservation would be implementation-defined. A conforming implementation could completely ignore them and validation would not be required. (I believe duplicates are not allowed to be fatal in [xml-id].)
2. All use of cross-references as part of representing the structural model of an ODF document would rely on identifiers and references that might use NCNAME-valued key sets but they would not be by usage of ID and IDREF, avoiding all collision issues with xml:id.
3. This is not a proposal. This is how I would have avoided comingling the use of identifiers that are essential to the structure and the arbitrary use of xml:id for some purpose independent of the ODF document structure. This would have an impact on interior xlink usage, too. Since this is not a proposal, there's no need to investigate whether there's an ODF-employed xlink case that would fail were an xml:id not available for a target. (I can imagine that happening in the single-file XML version of an ODF document.) The RDFa and [embedded] RDF cases would still rely on xml:id, but that's an overlay on the essential structure and a problem confined to those implementations that recognize and preserve RDFa and <rdf:RDF> annotations.
Since this approach would completely rewind what was done from 1.1 to 1.2 with regard to some structure-required cross-referencing, I would not ever consider this (apart from maybe allowing xml:id anywhere and [optionally] preserving them in an implementation, independent of what the standard says). I favor one of the alternatives that Rob has listed as an interesting way forward for ODF 1.3.
- Dennis
-----Original Message-----
From: [mailto:] On Behalf Of Svante Schubert
Sent: Tuesday, February 26, 2013 07:37
To:
Subject: Re: [office] The desirability of xml:id stability
[ ... ]
Ceterum censeo, the xml:id is like a public API for a document, the removal/change during a load/save roundtrip is similar to changing the anchor IDs of an HTML page, breaking all references into the document.
Best regards,
Svante
