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] Using RDF for Change Tracking serialization?


On Mon, 2011-05-16 at 11:39 -0400, robert_weir@us.ibm.com wrote:
> monkeyiq <monkeyiq@gmail.com> wrote on 05/15/2011 12:32:24 AM:
> 
> > 
> > Does anyone else think CT on the RDF is an interesting and valuable
> > idea?
> > 
> 
> I think it is interesting.  But I wonder whether the same applications 
> that find it challenging to support the flexible and dynamic GCT proposal 
> would also find it equally challenging to support ODF 1.2's flexible and 
> dynamic RDF support?

One huge plus here is that the xml:id referencing isn't needed as the
tracked changes have their own identifier system. So if, for example,
changetracking.rdf was nominated to contain the <delta:tracked-changes>
block then it could be preserved as is in an output document. Of course,
unless the ECT/GCT markup in content.xml was preserved then the
references from the changetracking.rdf would be invalidated, but that
would be the same problem if the <delta:tracked-changes> was in XML
inline in the content.xml.

If a current fragment
<delta:change-transaction delta:change-id="ct1">

is converted to 
nodeX rdf:type         delta:change-transaction
nodeX delta:change-id  "ct1"

The content.xml could go on using "ct1" as its identifier
<text:span 
  delta:insertion-type='insert-around-content'
  delta:insertion-change-idref='ct1'  
  text:style-name="bold-style">bold</text:span>

> 
> In other words, I don't think RDF necessarily reduces the complexity of 
> support changing tracking.  It replaces it with another, perhaps equally 
> complex task.

It would seem from initial inspection that RDF might be useful and
simple to use for <delta:tracked-changes> and perhaps ac:change
attributes. Though deletion of content in content.xml seems to offer
significant complexity if one tries to express those changes in RDF.

> 
> But that doesn't necessarily mean it is a bad idea.
> 
> -Rob
> 




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