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?


So how do you propose to refer to tracked changes from RDF if they places you are referencing don't have URI references?  

If you are using literals, no generic RDF system will know what you are doing at all.  And I don't see you doing anything with private identifiers that you can't do within the XML itself, since ODF already does that with other private (none ID-type) identifiers for other purposes.

 - Dennis

PS: Actually, I'm sorry I am asking, since I don't think this avenue is worth pursuing in the first place.

-----Original Message-----
From: monkeyiq [mailto:monkeyiq@gmail.com] 
Sent: Friday, May 20, 2011 19:29
To: robert_weir@us.ibm.com
Cc: dennis.hamilton@acm.org; office-collab@lists.oasis-open.org; 'Robin LaFontaine'
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]