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

[Patrick Durusau <patrick@durusau.net>]

Dennis,

On 02/04/2013 10:38 PM, Dennis E. Hamilton wrote:
> @Patrick
>
> Andreas has already reported that Gnumeric preserves structure but it does not retain the original xml:ids in its internal structure.  You've already heard from Oliver (orw) on the call that *none* of the OpenOffice-legacy implementations preserve xml:ids in their internal structure and the ids are synthesized on making a document persistent.  Michael Stahl has reported on this thread that "implementing the preservation of xml:id is actually surprisingly difficult."
As statements of what implementations currently *do*, all those 
statements are correct. That has no bearing on the question of the 
advantages of xml:id preservation or its difficulty.

Michael Stahl's comments, which you need to re-read, ventured a general 
opinion on the preservation of xml:ids for merging paragraphs. You 
really should quote in context or not at all.

None of which addresses my example of the re-use of data from 
spreadsheets precisely because addresses to the data are preserved.

> It seems inappropriate to second-guess implementers about this and I am going to refrain from that.
What's inappropriate is to echo any implementer's current code base as 
the default for any standardization effort.

You have not entertained any discussion of the benefits of xml:id 
preservation but are eager to end the discussion before it can get to 
that point.
> It seems to me that there is a lot more to clean up before xml:id stability becomes important.  It is my considered opinion that any such stability should be left to implementations and only if there is some sort of outcry for the need for interoperable implementation in a standard-specified way should anything be done about it at the ODF TC.  And yes, an ODF 2.0 would likely be the place to address significant breaking differences with respect to ODF 1.x.

Leaving stability up to implementations means that some implementations, 
not naming names, can claim conformance without offering advantages 
defined by a future version of ODF.

I don't see any advantage to ODF in taking such a position, There are 
advantages to implementers but those are not my concerns.

>   - Dennis
>
> MORE ANALYSIS
>
> I have discovered that it is relatively difficult to create an ODF 1.2 document that has xml:id attributes on any of its elements.  Many of the permitted occurrences are optional and it is not clear what would have them be there.
For a group that prides itself on abstraction, implementers are 
surprisingly concrete.

I posted a file yesterday where an arbitrary text string is preserved by 
an OpenOffice application.

Calling such a string xml:id, other than it's uniqueness feature, it is 
and remains just a string.

There isn't anything magical about it or different from any other unique 
string.

True, there is the merging case but that is a solvable one if you think 
about it.

> The elements that *require* an xml:id break down as follows:
>
> * The <text:changed-region> case is known.  It is also known that those xml:id attribute values routinely change from consumption to production (although the IDREF valued attributes on associated elements still refer to the correct ones on <text:changed-region> elements.).
Rather fanciful "analysis" if you want to call it that. How do you get 
"require[d]" change from consumption to production?

ODF 5.5.2 says nothing of the sort. Do you disagree?

> * The <text:meta-field> case is one where the persistence of the xml:id ID value is definitely important, since the field needs to be found from an external source by a fragment identifier matching the ID.  Since the arrangement is merely implementation-dependent, it is not possible to say more.  I don't know what implementations, if any, support this element and derive the field value in any way.
And your point would be?

> * The remainder are all <form:*> elements.  I managed to demonstrate those by creating a <form:text> and a <form:fixed-text> that was a label for the <form:text> field.  There were xml:id attributes whose ID value was lexically identical to the value of the form:id attribute on the same element.  There were cross-references using IDREF values too.  (The two ID values are "control1" and "control2".)  The ID values are not visible to the user, but the form:name values are.  I created this in LibreOffice 3.3.2 and opened and resaved it in Apache OpenOffice 3.4.1.  The ID values and the form names were unchanged.  I tried the document in Microsoft Office 2013 Word and the form did not survive the trip, so there is nothing to learn there about the unlikely preservation of xml:id values at this point.
Again, you are keying off the term "xml:id" as though it is a talisman 
of some sort.

I posted to Andreas an example where user supplied text strings are 
persisted last night.

Yes, current implementations appear to not have a slot for writing down 
xml:ids or xml:idrefs where they are found.

Ho-hum.

Yet, current implementation write down a large number of other values 
and references between those values, such as style sheets.

We could call them "h" for Hamilton ids and define the same 
characteristics as xml:ids (except for the requirement of start name 
characters) and have the same capabilities.

I am going to start posting on the advantages of stable xml:ids and 
related issues.

What current implementations do is a starting point, not a boundary for 
standards development.

Hope you are at the start of a great day!

Patrick

> -----Original Message-----
> From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Patrick Durusau
> Sent: Monday, February 04, 2013 14:34
> To: Andreas J Guelzow
> Cc: office@lists.oasis-open.org
> Subject: Re: [office] The desirability of xml:id stability
>
> Andreas,
>
> On 02/04/2013 04:36 PM, Andreas J Guelzow wrote:
> > On Mon, 2013-02-04 at 14:30 -0700, Patrick Durusau wrote:
> >
> > > 3) What I am missing is some evidence, other than your saying it, that
> > > preservation of xml:ids is any harder than preserving any other
> > > attribute value.
> [ ... ]
>
> That is there are plenty of specified attribute values that are
> persisted. See any stylesheet attribute whose value is chosen by a user.
>
> I don't know how that preservation is different from preserving an
> "arbitrary" string?
>
> [ ... ]

--
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Former Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau