RE: [office-collab] Using RDF for Change Tracking serialization?

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

The reason for preserving xml:id is that they can be referenced by any URI from other material including RDF/XML but not limited to that (and from outside the package, if someone has a URI scheme for that).  So we have this problem already, no matter what happens with change tracking.

I would have preferred that we had never introduced xml:id for any other use, since we already have private identifier systems and we could have maintained them instead of going through a limited conversion to xml:id on what appear to have been solely ideological grounds.  We broke down-level compatibility by fixing something that wasn't broken, in my considered opinion.

 - Dennis

-----Original Message-----
From: monkeyiq [mailto:monkeyiq@gmail.com] 
Sent: Friday, May 20, 2011 19:51
To: dennis.hamilton@acm.org
Cc: office-collab@lists.oasis-open.org
Subject: RE: [office-collab] Using RDF for Change Tracking serialization?

On Tue, 2011-05-17 at 12:26 -0700, Dennis E. Hamilton wrote:
> ...
> I agree that xml:id attributes and there values should be preserved 
> when the element having them is preserved in the document structure.
> (If the element is swept up in a deletion, it seems to me that so is 
> the xml:id, and it is not available for reuse until the deletion is 
> accepted and no longer tracked.)  [This creates a problem that has to 
> be resolved if moves are treated as a combination of a deletion and an 
> insertion.]

I don't see that the value of an xml:id need be special. If an application wants to change it that's fine IMHO. But it needs to do something like changeid( oldid, newid ) where references in RDF to oldid are changed to newid so that links from RDF to content.xml are preserved. Of course this breaks RDF outside the ODF file, but that RDF could link to a triple inside the ODF file instead of the xml:id if it wanted stability.

KOffice changes xml:id values because it was seen that the system should be able to reassign xml:id values of it's choosing to avoid having to select new ones which do not clash with existing ones.

> 
> I'm not sure that *any* implementation of ODF as a native format 
> preserves xml:id, and we should check for that.  I would definitely be 
> surprised that xml:id is preserved by import into a non-ODF document 
> processor where the manipulated document is then exported back to ODF 
> format.  (I don't expect that RDF/XML and embedded RDFa will survive 
> such a journey either.)

This is exactly what happens in recent builds of abiword. For example, during a copy and paste operation non ODF content is available on the clipboard. In the paste the encoded xml:id values are sought from the clipboard content, updated, and the RDF (if any) associated with the source copy/cut is relinked to the pasted content.

Links and RDF are also preserved across non ODF save/load cycles. For example loading an ODT with RDF and saving it to abw format, closing abiword, opening abiword and loading the abw and saving back to ODT does what one would hope. That being RDF preservation and any RDF pointing to xml:id links being preserved.

I don't find this so surprising, it is more a matter of wanting it to happen.