[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] The desirability of xml:id stability
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: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Svante Schubert Sent: Tuesday, February 26, 2013 07:37 To: office@lists.oasis-open.org 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]