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 02/04/2013 10:38 PM, Dennis E. Hamilton wrote:

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


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.


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!


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


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

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