OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


<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-----
> From: office-collab@lists.oasis-open.org [mailto:office-
> collab@lists.oasis-open.org] On Behalf Of monkeyiq
> Sent: Thursday, October 20, 2011 16:29
> To: dennis.hamilton@acm.org
> Cc: 'Patrick Durusau'; office-collab@lists.oasis-open.org
> Subject: RE: [office-collab] Draft consensus report: Change Tracking
> on the RDF itself?
> 
> 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).
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: office-collab-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: office-collab-help@lists.oasis-open.org
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]