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 05/02/13 04:38, 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."

starting with version 3.2, OpenOffice.org Writer has this _partially_
implemented, i.e. it will preserver xml:id on some but not all elements.

for a complete list see:
http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/RDF_metadata#Status

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

as an aside, from an RDF metadata perspective a more serious open
question is that when some content element is copied, the copy/paste of
the RDF metadata referencing that element via its xml:id is left
completely unspecified by ODF, which is unlikely to yield similar
results in different implementation.  (the problem is that the RDF
graphs have no "natural hierarchy" (they are not trees), and of course
by the very nature of the feature ODF implementations cannot assume
particular semantics of the RDF properties that happen to be used in
some file.)

> 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.  The elements that *require* an xml:id
> break down as follows:

in many cases optional xml:id attributes were added to elements in ODF
1.2 for the RDF metadata feature.

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

in OpenOffice.org these xml:ids are newly generated on export.

> * 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 element is supported in OpenOffice.org, but there is no UI for it,
so you have to use the API to insert it (or load an ODF file that
contains it).

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

i believe in OpenOffice.org the xml:id implementation for these elements
is actually distinct from the one i've cited above, and so it is
possible in principle to get duplicate xml:id attribute values for
these; but i don't know if the xml:id values are _actually_ preserved or
if they merely happen to be generated in a superficially consistent
manner on export.

another case where OpenOffice.org may generate xml:id but does not
preserve it is text:list.

regards,
 michael

-- 
Michael Stahl | Software Engineer
Platform Engineering - Desktop Team
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com


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