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