RE: [office-collab] Location of text:tracked-changes element

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

Although I don't think these are compelling matters, I want to be clear about the scope issues:

ODF allows for sub-documents embedded in the main document.  In some implementations, the package form is also embedded in another package (i.e., it is a Zip).   In other cases, the parts of the sub-document are organized by using a shared path prefix on the names of the parts.   The latter "nested" parts are in the manifest of the overall document, and the shared path prefix will also appear in the manifest for the purpose of identifying it as the prefix of a subdocument.  There is only one manifest for all of the parts of the main document (but an embedded package occurs as a single file, so nothing within it can be viewed as under the XML of the overall document).  [This is material with regard to digital signature of the overall document and also to encryption in the ODF 1.2 provisions.]

If a "nested" subdocument had change-tracking before it was introduced into the current overall document, there becomes the question, why mess with its change-tracking to accomplish that?  Also the nested subdocument might be of a different kind than the overall document (e.g., a spreadsheet embedded in a text document).  It might even be a different version of ODF since there is no restriction about that in the ODF specification.

This is something to be careful about.

Finally, a single, somewhere-global collection of the counterpart of <text:tracked-changes> will likely  introduce a global-to-the-document non-ID identification scheme by which the out-of-line change-tracking information can be referenced from the in-line change marks, wherever they are.   I'm not sure this eliminates scope issues and I wonder if it is a good technical trade-off even if it does.

I think my principle concern, apart from these nits, is that we  not hand-wave away the scoping that applies in ODF 1.2 change-tracking until we are clear why it is that way and what its value is.

 - Dennis

SIDE NOTE

There are technical differences between the single-XML document model and the package model where the portions are contributed by separate XML documents in the package.  The most fundamental difference has to do with how cross-references may occur.  XML provides no mechanism (in the XML specification itself) for cross references from one XML document to another.   Put more simply, an attribute value of IDREF type can only refer to the one element in the same XML document that has an attribute of type ID with matching value.  There are many cases (e.g., reference to styles) where the ODF document has, in effect, its own domains of references and of targets that match on names.  These domains work across the document,  not just within a single XML document of the package.

The ODF 1.2 Change Tracking relies on ID and IDREF valued attributes to connect the change-marks in the text stream with the <text:changed-region> elements in the <text:tracked-changes> element of some scope.  There are ways to continue to use ID and IDREF when the source and target are in the same XML document, and to use URIs to cross-reference to an ID (now a fragment identifier) of an element in a separate XML document.  It would take some massaging to do, but it might be workable.   This is a hybrid way of getting the global-to-the-document ID-based identification scheme.  



-----Original Message-----
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com] 
Sent: Thursday, April 21, 2011 04:38
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Location of text:tracked-changes element

(Sorry to be slow in replying to this.) In terms of how the GCT proposal works, these are the assumptions:

1. The ODF document is semantically considered to be a single XML file (the single file format) and dividing it into separate parts in a zip is not semantically important as far as change tracking is concerned. The scope of the changes is the whole document.

2. Where the delta:tracked-changes goes is not important, but there must be only one of them (see 7.2.2 Rule 1) because order of the changes is important (see 3 list item number 5). 

The Use case samples are only samples - the subcommittee can decide where to put the delta:tracked-changes element. Dennis points out there are scope issues for the current text:tracked-changes and where it appears, but there should not be these issues for the GCT proposal.

Hope this helps.
Robin


On 13/04/2011 01:33, monkeyiq wrote: 

	Hi,
	  In the Generic CT, should text:tracked-changes exist as the first
	child of office:text or as a sibling of office:automatic-styles. ie, in
	the later perhaps after the automatic styles but before the office:body.
	
	  FWIW the relaxng schema odt-delta.rng 6836 2010-07-30 14:15:03Z nigelw
	validates the first case location and not as the second.
	
	  As an aside, I started with using the second placement as it seemed
	the ct element related to content inside the office:body. In KOffice gct
	it is expected to be inside the office:text (ie, koffice validates
	placement ok with the rng schema).
	
	  Although I now have abiword able to place in either/both location and
	read from either I thought it best to clarify where exactly it is
	desired to have this element appear: inside office:text or at a sibling
	level with automatic-styles, or somewhere else?
	
	
	
	---------------------------------------------------------------------
	To unsubscribe from this mail list, you must leave the OASIS TC that
	generates this mail.  Follow this link to all your TCs in OASIS at:
	https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
	


-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php