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


On 26.02.2013 20:04, Dennis E. Hamilton wrote:
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.
xml:id were introduced with ODF 1.2 to be able to refer to the elements from RDF resources within the package and to exchange in general the multiple existing IDs without an ID schema type by a unique one.
Referring from outside the package is very desirable and already on the proposal queue, see https://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_using_URL_fragment_identifiers_for_ODF_media_types
Mathias Bauer (former OOo Writer lead) even stated that opening a document at a certain spot, would be a low hanging fruit.
 
Regarding the changeability, it was not mentioned in ODF 1.2 nor in the HTML specification to not change these IDs for anchors, the access points within a document, as otherwise external links are broken, as it is as obvious as the label: "your coffee might be hot", but much more difficult to specify. As the user is allowed to change the xml:id, but it should not occur without a reason.


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].)
This simplification of design would unfortunately create complexity on the abstraction layer from the XML. As all boilerplate XML elements (e.g. office:body) might possess IDs, enabling the ability to have multiple IDs (= URIs) on the same component (=Data), which should be avoided by web design principles.
In ODF 1.2 we focused therefore on those elements that were able to contain (text) data.

 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.
What is the problem you are trying to solve here, Dennis?

 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.
If someone has a bug in its implementation, like randomizing external identifier (xml:id), it has to be fixed, otherwise the overall value of ODF is being lowered, as that application would be the weakest chain, destroying information in a document exchange.
Using the same data format across applications requires responsibility, even if the application has currently no advantage of this feature. Especially, when this issue is as easy to fix as xml:ids.

Thanks,
Svante



 - 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]