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

[Oliver-Rainer Wittmann <ORWITT@de.ibm.com>]

Hi,

On 04/02/13 20:55, Michael Stahl wrote:
> On 04/02/13 18:00, Dennis E. Hamilton
wrote:
>> CASE 2: RDF in the same package
and elsewhere.  (Not just the RDFa in
>> content.xml itself)
>> 
>> ODF 1.2 permits RDF parts to
be included in a document that refer into
>> elements of the document structure.
 These RDF parts need a way to identify
>> the elements being referenced,
and fragment IDs in URIs of the RDF terms are
>> the common means.  
>> 
>> Likewise, when the RDF is extracted
from the document (e.g., via a GRDDL
>> procedure) or is otherwise
external from a document, that RDF can make use
>> of the ODF Package and OWL
Document OWL classes to continue to refer to
>> specific elements internal
to the ODF package.  To the extent that a
>> revision of the document is
logically the same work with respect to the
>> nature of the RDF about it,
not preserving fragment IDs becomes a problem.
> 
> yes.  (though OWL classes
are not actually necessary for that, just
> referencing the xml:id of an element
is enough.)
> 
>> (It is also a challenge to
deal with the fact that ODF currently lacks a
>> means for creating a location-independent
entity identification of a
>> document.  Something is
needed for where different occurrences of instances
>> are to be taken as logically
the same document.  This requires something
>> that can work as a persistent
URI or URN for a document that is relatively
>> instance-independent and where
the document is not necessarily found only at
>> a unique URL location on the
Web.)
> 
> is this "something" in
any way specific to ODF?  i'd assume this is a
> more general problem.  although
it's only a problem for documents on the
> local file system; if the document
is _actually_ on the web, it's a
> non-issue because if your web URIs
aren't stable then you're doing it
> wrong anyway.
> 
>> Finally, it is not to be expected
that all implementations will be in a
>> position to adjust RDF within
packages to align with changed xml:id ID
>> values in order to perserve
the referential integrity from such metadata.
>> Some implementations will simply
not deal with such RDF and they may but
>> need not preserve that RDF
within the package.  (There are pros and cons
>> about this.  Having mystery
material can be a problem for document
>> safety/security and also for
documents that are digitally signed when there
>> is implementation-unknown material.)

> 
> from my experience the main problem
is that implementing the
> preservation of xml:id is actually
surprisingly difficult, due to the
> uniqueness constraint that has
to be maintained at all times; at least
> in OpenOffice.org Writer, whose
internals differ significantly from what
> a naive reader of the ODF specification
would expect, operations such as
> Splitting/Merging, Undo, Change
Tracking and Copy/Paste are just the
> most obvious ways in which things
can go wrong...
> 
>> CASE 3: ODF 1.2 CHANGE TRACKING
>> 
>> Depending on how references
to portions of documents involving tracked
>> changes happens, there can
be a problem with the preservation of xml:id
>> attributes.  
>> 
>> In ODF 1.0/1.1/1.2 the connection
of change information with the places in
>> the document where the change
applies is accomplished by the xml:id ID value
>> on a <text:changed-region>
element.  It is also the case that element start
>> tags with xml:id attributes
can be swept up into <text:deletion> elements
>> that carry removed material.
 Those xml:ids would need to be preserved,
>> since the deletion can be rejected
in a later edit.  (This situation has
>> remarkable consequences for
RDF now referencing an element that is
>> (partially) deleted.) 
> 
> ah yes... i once spent a day thinking
about how to represent xml:ids of
> merged paragraphs in the change
tracking info such that both accepting
> and rejecting the tracked change
yields good results and no additional
> ODF attributes are necessary due
to the uniqueness constraint on xml:id.
>  i don't remember what my
preferred solution was, but Oliver-Rainer
> didn't like it at the time so maybe
it wasn't a good idea  :)

Unfortunately, I did not even remember
the discussion on it.

Just for my interest: Do you remember
the discussed solutions?

> 
>> (Note that this xml:id case
>> should actually be about all
ODF 1.x attributes having values of type ID,
>> since uniqueness must be preserved
across all of them.  The xml:id ones are
>> the only ones automatically
accessible via fragment values in URI
>> references.)
> 
> the ODF 1.2 schema only has xml:id
as an ID type attribute;  all ID
> attributes in older ODF versions
were deprecated in favour of xml:id
> with ODF 1.2, and their types were
changed to "string" so they could
> have the same value as xml:id (for
the benefit of ODF 1.1 consumers).
> 
> 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
> 
> ---------------------------------------------------------------------
> 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

> 

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