OpenDocument - Adv Document Collab SC

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

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 >

The situation with profiling of metadata and dealing with constraints and fixed relationships is interesting. On aspect not dealt with has to do with xml:id on elements that are not metadata but which are used to refer to in metadata which may not be in the same file. There may be references by something more active than metadata as well, of course. I think there is an intersection, but the union is greater than either situation. Dealing with xml:id as fragment identifiers in a safe way may also serve some of the safety considerations around metadata, which is all to the good. But I think the issues you raise around metadata safety are on top of this to the extent there is intersection. Thanks for the links. I did not take notice of this at the time. - Dennis
Original Message----- From: robert_weir@us.ibm.com [ mailto:robert_weir@us.ibm.com ] Sent: Friday, September 28, 2012 09:59 To: dennis.hamilton@acm.org Cc: ODF TC Collaboration SC Subject: Re: [office-collab] 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://incubator.apache.org/openofficeorg/translate.html > http://www.robweir.com/blog/publications/berlin-plugfest/ODFMetadata.pdf < 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 >