RE: [office] The desirability of xml:id stability

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think it is generally agreed that there are use cases for which stability of xml:id ID values is desirable.  However,

 1. There is no such requirement in ODF 1.0/1.1/1.2 and implementations have managed to preserve structure without having to preserve lexical agreement (a nice distinction Rob pointed out on today's call).  However obvious stability at the lexical level is claimed to be, there are tens-of-millions of implementation instances out there that don't do it that way.  

 2. On today's call I claimed that there is no demonstrated need for xml:id stability on behalf of change-tracking.  (The automatic generation of lexical values is not a change in the current situation.)  That does not mean there are not useful cases.  But there is no expressed dependency of the CT work on xml:id at all and certainly not on xml:id stability.  If that were crucial to the CT work, that needs to be established by bringing the CT work to a point where this is clear as a technical requirement.  Then the requirement could be dealt with on a concrete basis.  For example, it might be a mandatory part of CT conformance but only a recommendation otherwise.

 3. Oliver and Thorsten pointed out, in their words, that it is not practical, at this stage, to clean-sheet much of ODF (although the CT work might be a worthy exception).  The agreement of implementers on the desirability of swallowing an xml:id stability requirement is essential, although it could be implemented unilaterally by an ODF 1.2 producer now.  There is no prohibition to preservation of xml:id lexical values.  It could even be worked up to gradually, to minimize the prospect of destabilizing an established implementation.  An ODF consumer doesn't need to know, since the structure is conveyed properly either way.  (For features a consumer does not support, how they are handled without failing is about far more than xml:id.  There is no requirement that a consumer produce/preserve anything that it does not support.)  

 4. A big part of the problem here is that this is not low-hanging fruit and it is not something that most users of ODF-based products may ever be aware of (until something already-expected ceases to work).  ODF is not a hand-authored XML application.  

I repeat myself: it is important that progression of ODF versions provide for migration of implementations over time and be tolerant of the need for down-level compatibility for meaningful periods of time.  It is important to be ever mindful that ODF documents exist and that ODF-supporting software is not replaced on anyone's fixed schedule.  And it is not up to us to tell implementers how easy it is.  It is up to us to appreciate what the concerns of implementers are and what the priorities are in their worlds.

A few comments in-line below.

 - Dennis
    

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Svante Schubert
Sent: Monday, March 04, 2013 03:30
To: office@lists.oasis-open.org
Cc: dennis.hamilton@acm.org
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 
[ ... ]
 
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.

[ ... ]
	
	 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?

<orcmid>
  I would be making the structural preservation of the ODF document independent of the use of xml:id as an anchor point for incoming references.  Note that xml:id stability could be preserved, just not relied upon for the ODF structure.  
  It is how I would cut the knot between arbitrary reference into fragments for some arbitrary purpose and the essential structure of the ODF document.  I would make the essential structure the sole responsibility of ODF producers and have that independent of xml:id stability.
  But this is all hypothetical.  It is not consistent with the current state of xml:id in ODF 1.2 documents.  It is more to illustrate that rather than increase structure dependency on xml:id, it might be better to have reduced it.
</orcmid>  
	
[ ... ]

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.

<orcmid>
    Now it's an easy to fix bug?  
</orcmid>

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