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


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

It seems inappropriate to second-guess implementers about this and I am going to refrain from that.  

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.

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

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

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

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

[ ... ]

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