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

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