office-collab — archive

Identifier Invariance in ODF Documents

From: Rob Weir <[email protected]>
To: [email protected]
Date: Fri, 28 Sep 2012 16:59:00 -0000

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 [email protected] wrote on 09/28/2012 12:27:23 PM: > From: "Dennis E. Hamilton" <[email protected]> > To: "ODF TC Collaboration SC" <[email protected]>, > Date: 09/28/2012 12:30 PM > Subject: [office-collab] Identifier Invariance in ODF Documents > Sent by: [email protected] > > 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: [email protected] > For additional commands, e-mail: [email protected] >