OpenDocument - Adv Document Collab SC

 View Only

  • 1.  Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-20-2011 03:04
    Hi, One area which after initial discussion there seems to be no opposition to having is change tracking on the RDF for the ODF document. http://markmail.org/message/4t6zlmiieno2g7on IMHO this is a very important feature to have as a change tracked content.xml really wants changes to the RDF associated with the document text to also be seen. I'm not sure if it should be in the consensus report or not, but I thought I'd give a shout now in case it should be there ;)


  • 2.  RE: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-20-2011 03:46
    Funny, I don't think an ODF producer should be required to pay attention to the RDF at all, except maybe the embedded RDFa. But not manifest.rdf and any other *.rdf components in the package. There's nothing in the ODF specification for dealing with RDF package parts in any way whatsoever. It is a no-man's land. Change tracking seems a very messy business, especially since it has to deal with incoming references to xml:id fragment identifiers in parts of the content.xml. Without knowing what the semantics of the incoming reference is, it is not clear what is appropriate "change-tracking."
    Original Message


  • 3.  Re: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-20-2011 08:39
    Dennis, On 10/19/2011 11:46 PM, Dennis E. Hamilton wrote: Funny, I don't think an ODF producer should be required to pay attention to the RDF at all, except maybe the embedded RDFa. But not manifest.rdf and any other *.rdf components in the package. Curious what you mean by "...required to pay attention to RDF at all...." ? Producers would be the components that produce RDF, whether in the manifest or RDFa. Did you mean consumers? There's nothing in the ODF specification for dealing with RDF package parts in any way whatsoever. It is a no-man's land. Change tracking seems a very messy business, especially since it has to deal with incoming references to xml:id fragment identifiers in parts of the content.xml. Without knowing what the semantics of the incoming reference is, it is not clear what is appropriate "change-tracking." The treatment of package parts does need to be beefed up, I will find the time to open a series of issues for RDF in 1.3. It also isn't clear what you mean by: Change tracking seems a very messy business, especially since it has to deal with incoming references to xml:id fragment identifiers in parts of the content.xml. "incoming"? From where? There seems to be some confusion about the nature of change tracking in ODF. At least in my opinion it isn't about tracking changes in the ODF XML. It is about tracking changes to the document instance, changes that are represented in XML so the next application in line knows what changes were made, accepted or rejected, etc. Yes, we have to make reference to ODF elements and attributes as part of recording changes, because that is how the changes will be manifested to the next application but isn't diffing the XML as though we were editing the XML. To put it another way, ODF isn't about editing XML, it is about XML representing an editing process and/or product for interchange. Not the same thing. Hope you are at the start of a great day! Patrick
    Original Message


  • 4.  RE: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-20-2011 17:36
    To clarify, I completely agree that change-tracking in office productivity documents is about the user-perceived document as presented by a consumer. However, it has to be implemented in the markup and I was raising limitations of the markup that would make preservation of an RDF interdependency meaningful. - Dennis MORE DETAIL If there is RDF markup about the document in some *.RDF document in the package, it refers to content via references of some form, using instances of the OWL cases provided for that purpose. This allows reference to material in the content.xml file (and perhaps elsewhere). Although a producer that provides that RDF presumably does so based on some relationship between the RDF and the content.xml (using xml:id values as targets or using XPath or something), it is near impossible for a consumer to know what that interdependency is (unless it is the very same producer). So making modifications to the visible text of the ODF document will, if it applies to areas that are referenced by RDF elsewhere in the package, potentially break the connection. It is not clear how change-tracking of the material changed can compensate for the fact that there is RDF that depends on the unmodified material. There is a referential integrity issue. Note that these issues may also arise with RDFa cross-referencing within content.xml too, just as they arise with cross references and bookmarks in material that is impacted by changes (and their change-tracking).
    Original Message


  • 5.  RE: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-20-2011 23:29
    I think it would be a great shame not to include change tracking of RDF in the specification. Even if the inclusion lists it as an "optional" area that applications might like to implement. Not covering RDF in the specification may well lead to cases where applications use their own model for such functionality and such models may not be compatible across multiple ODF tools. On Thu, 2011-10-20 at 10:35 -0700, Dennis E. Hamilton wrote: > To clarify, > > I completely agree that change-tracking in office productivity > documents is about the user-perceived document as presented by a > consumer. However, it has to be implemented in the markup and I was > raising limitations of the markup that would make preservation of an > RDF interdependency meaningful. > > - Dennis > > MORE DETAIL > > If there is RDF markup about the document in some *.RDF document in > the package, it refers to content via references of some form, using > instances of the OWL cases provided for that purpose. > > This allows reference to material in the content.xml file (and perhaps > elsewhere). Although a producer that provides that RDF presumably > does so based on some relationship between the RDF and the content.xml > (using xml:id values as targets or using XPath or something), it is > near impossible for a consumer to know what that interdependency is > (unless it is the very same producer). When an RDF subject is linked to an xml:id in content.xml via the predicate URI http://docs.oasis-open.org/opendocument/meta/package/common#idref Then the association is explicit and near impossible for a consumer NOT to know. Of course, some care must be exercised by a program when editing document fragments that contain xml:id values. For example during a copy and paste clashing xml:id values might occur and that situation will need to be explicitly addressed by the program. Cross application copy and paste with RDF works right now, preserving the links between RDF and the content... Note that this copies both the xml:id from the content.xml and the relevant RDF triples over the clipboard... http://monkeyiq.blogspot.com/2011/09/copy-and-paste-with-semantics.html > > So making modifications to the visible text of the ODF document will, > if it applies to areas that are referenced by RDF elsewhere in the > package, potentially break the connection. It is not clear how > change-tracking of the material changed can compensate for the fact > that there is RDF that depends on the unmodified material. There is a > referential integrity issue. Yes, connections can be broken. If there was an xml:id before and the user deleted that span of the document then there might be RDF that no longer references the content.xml. I didn't think that RDF depended on unmodified material. Consider when the content.xml file contains ...<text:meta xml:id="foo">bar</text:meta>... and is changed to ...<text:meta xml:id="foo">plan9 rocks</text:meta>... of course, if the RDF that links to "foo" is about miscellaneous names used for identifiers then it is probably not likely to be relevant to the updated "plan9 rocks" text. So the RDF that is associated with the span might have to be changed if the text content of the span changes it's meaning significantly. This is similar to if the span was a heading and the user wanted to change it to starting a paragraph, the style for the span might have to be modified as well as the text. > > Note that these issues may also arise with RDFa cross-referencing > within content.xml too, just as they arise with cross references and > bookmarks in material that is impacted by changes (and their > change-tracking). > >


  • 6.  RE: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-21-2011 00:26
    Since there is nothing in ODF, now, that affords compatibility across tools, especially (but not limited to) interdependencies between RDF and the ODF-specified document, I don't see how adding change-tracking helps the situation. That is my point. - Dennis
    Original Message


  • 7.  RE: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-21-2011 18:53
    <office-collab@lists.oasis-open.org> wrote on 10/20/2011 08:25:59 PM: > > Since there is nothing in ODF, now, that affords compatibility > across tools, especially (but not limited to) interdependencies > between RDF and the ODF-specified document, I don't see how adding > change-tracking helps the situation. That is my point. > Interoperability is not a pre-req for change tracking. Suppose we never defined what the word "italics" meant. We just called it "foo". We would not have interoperability of that attribute. But we could still track changes related to it. Ditto for foreign elements/attributes. -Rob > - Dennis > >
    Original Message


  • 8.  Re: [office-collab] Draft consensus report: Change Tracking on the RDF itself?

    Posted 10-20-2011 17:12
    The change tracking of metadata, especially for ODF document in business processes seems very important to me, too. On the other hand, I share Dennis opinion that RDF CT is not in the responsible of an ODF application, but should be covered by a third party application and / or the W3C RDF standard itself. In general the change-tracking of pictures and the change-tracking of RDF metadata seems to be on the same level. We do not track the changes within a picture, neither. Still it would be important for a user to undo the exchange of a picture. - Svante Am 20.10.2011 05:46, schrieb Dennis E. Hamilton: > Funny, I don't think an ODF producer should be required to pay attention to the RDF at all, except maybe the embedded RDFa. But not manifest.rdf and any other *.rdf components in the package. > > There's nothing in the ODF specification for dealing with RDF package parts in any way whatsoever. It is a no-man's land. Change tracking seems a very messy business, especially since it has to deal with incoming references to xml:id fragment identifiers in parts of the content.xml. Without knowing what the semantics of the incoming reference is, it is not clear what is appropriate "change-tracking." > >
    Original Message


Related Content