OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]