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
- From: Oliver-Rainer Wittmann <ORWITT@de.ibm.com>
- To: office@lists.oasis-open.org
- Date: Tue, 26 Feb 2013 15:52:27 +0100
Hi,
minor correction regarding my statement
on the call regarding preserving xml:ids in Apache OpenOffice:
I did not say that *none* of the xml:ids
are preserved, simply because I do not know it. I just said that the one
or the other xml:id (esp. whose which are controlled by Apache OpenOffice)
might not be preserved during an open-save-cycle.
Mit freundlichen Grüßen / Best regards
Oliver-Rainer Wittmann
--
Advisory Software Engineer
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Beim Strohhause 17
20097 Hamburg
Phone: +49-40-6389-1415
E-Mail: orwitt@de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzende
des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294
From:
"Dennis E. Hamilton"
<dennis.hamilton@acm.org>
To:
"'Patrick Durusau'"
<patrick@durusau.net>, "'Andreas J Guelzow'" <andreas.guelzow@concordia.ab.ca>,
Cc:
<office@lists.oasis-open.org>
Date:
05.02.2013 04:38
Subject:
RE: [office]
The desirability of xml:id stability
Sent by:
<office@lists.oasis-open.org>
@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."
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
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:
* 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
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?
[ ... ]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]