Re: [office-collab] Identifier Invariance in ODF Documents

[robert_weir@us.ibm.com]

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

office-collab@lists.oasis-open.org wrote on 09/28/2012
12:27:23 PM:

> From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
> To: "ODF TC Collaboration SC" <office-collab@lists.oasis-open.org>,

> Date: 09/28/2012 12:30 PM
> Subject: [office-collab] Identifier Invariance
in ODF Documents
> Sent by: office-collab@lists.oasis-open.org
> 
> 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: office-collab-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: office-collab-help@lists.oasis-open.org
>