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

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

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


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]