Identifier Invariance in ODF Documents

This is related to the concept of "edit-safe metadata" that I gave a presentation on last year:
http://incubator.apache.org/openofficeorg/translate.html
http://www.robweir.com/blog/publications/berlin-plugfest/ODFMetadata.pdf
Referential integrity is one issue, but there are others.
Toward the end I suggest a possible solution.  In the end it is an issue of hidden or private constraints and the solution is to declare what the constraint is.
-Rob
 wrote on 09/28/2012 12:27:23 PM:
>
From: "Dennis E. Hamilton" <>
>
To: "ODF TC Collaboration SC" <>,
>
Date: 09/28/2012 12:30 PM
>
Subject: [office-collab] Identifier Invariance in ODF Documents
> Sent by: 
>
> This may be tangential to CT, but maybe not.  >
> I will use the current ODF 1.2 specification since I have not
> followed the intricacies of MCT.  I think the considerations are the same.  >
> In ODF 1.2, there is now increased use of xml:id as an attribute.
> It is used, for example, to cross-reference among places where
> changes have been made to the details about the change in a
> <text:tracked-changes> element.  >
> There are also uses of identifiers that cross-reference by other
> than ID and IDREF attribute-value types.  That figures in as well,
> but the use of ID, IDREF, and xml:id is what I want to focus on.  >
> Another use of xml:id is as a fragment identifier for reference via
> an HREF from elsewhere in the same XML document (e.g., content.xml)
> or between two XML documents (e.g., an RDF document and content.xml)
> in the package.  >
> Because, in general, it is not possible to know what xml:id
> attributes will be the target of HREFs from other parts of the
> package, including RDF parts and parts of an unknown character,
> there is a problem if the xml:id values and references to them are
> not preserved when the elements involved are carried between the
> consumption of a document and the production of a derived document
> (a revision or some repurposing).  >
> The problem is that an ODF processor is not required to be prepared
> to recognize where all the references into a part by fragment
> identifier may be, and to update them.  >
> This is a similar kind of problem to ones that Oliver has been pointing out.  >
> So, a processor that is intended to preserve round-trip use in an
> interchange setting may need to keep existing identifiers invariant
> so long as the document components that establish them are retained
> in the processed result.  >
> Whatever is done in change tracking, it should not prevent the
> preservation of identifiers in this manner.  >
> Note that the preservation of identifiers works consistently when an
> element is decapitated or completely deleted, its start tag is part
> of material preserved from in the change-tracking of the deletion
> and any xml:id in that start tag is going to go wherever that start
> tag goes.  In ODF 1.2 change tracking, that also means identifiers
> in change-mark elements will go with those elements when swept up in
> a deletion.  (There are other elements that cross-cut XML hierarchy
> that can have their associations severed in this kind of activity too.)
>
> Of course, processors could preserve referential integrity by
> dealing with all inbound references and repair them when an  xml:id
> is emitted in the result of document processing.  But I don't think
> ODF can required that.  ODF also should not prevent processors
> maintaining identifier invariance as a simple interoperability
> assurance.  (This also deals with foreign-element cases, although I
> don't particularly favor preservation of not-understood foreign elements.)  >
> Something y'all may need to think about.  >
>  - Dennis  >
>
>

---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail:   >