RE: [office-collab] Re: Counting in Access Paths

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

Let's get back to the subject at hand.

  1. The use of one-way absolute (i.e., position-rigid) hierarchical references are brittle and cannot survive 
     processing that alters such paths without requiring any processing of the markup (at the markup level) 
     to find and adjust the references, delete the references, or leave the document in a damaged condition.

  2. The use of unique ID values in a bidirectionally-verifiable linkage does not have those problems and is a technique already required of ODF processors.

  3. I don't believe (1) is *essential* to MCT.  If it is essential, I would say that MCT is fatally flawed.

  4. What is the technical barrier to using a mechanism like (2) for MCT?  Is it so objectionable that there are empty elements that serve as markers in the texts that have tracked changes? 

  5. The making of untracked changes in content that is subject to a tracked change is a problem in all approaches.  It seems that (2) is safer and there may be further safeguards so that a change is not misattributed.  That's different than having the document be broken, as would happen with (1).

I am unclear what the attachment to absolute positional offsets comes from.  Is it really essential?

 - Dennis
 
-----Original Message-----
From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Svante Schubert
Sent: Sunday, October 21, 2012 04:33
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Re: Counting in Access Paths

Hi John,

I am glad to hear that you share the concerns of the important use case of "a document with tracked changes being edited by an implementation not supporting CT seems to completely break the referencing model.  "
Especially as my current pre-release of MS Office 2013 with ODF 1.2 support simply throws away all my change-tracking information. I am glad to hear that Microsoft takes this use case serious and looking forward to work with the full MS Office 2013 version supporting the important change-tracking use case. 

Enjoy your week-end,
Svante

On 19.10.2012 13:12, John Haug wrote:


	I have similar concerns, because I haven’t seen yet how they are avoided.  The case of a document with tracked changes being edited by an implementation not supporting CT seems to completely break the referencing model.  See my previous mails from October 1, “Counting issues, etc”.

	 

	John

	 

	From: office-collab@lists.oasis-open.org [mailto:office-collab@lists.oasis-open.org] On Behalf Of Robin LaFontaine
	Sent: Thursday, October 18, 2012 2:05 AM
	To: office-collab@lists.oasis-open.org
	Subject: Re: [office-collab] Re: Counting in Access Paths

	 

	I agree with your concerns, Dennis, and am surprised implementors do not seem to worry about this issue. OT has, we are told, been proved to work in a forwards direction when by definition all the 'edits' will be tracked and executed. Working backwards (from existing to previous version, i.e. tracked change) when not all the changes will be tracked, and not all accepted, is a different problem, IMHO. However, it is simple enough (though it will need a good bit of effort) to demonstrate whether or not this is a real concern - we need a specification of how it works and some implementations!
	
	Robin

	On 17/10/2012 21:38, Dennis E. Hamilton wrote:

		I'm having a terminology problem here.
		 
		As far as I'm concerned, s="/2/10" and e="/3/18" are absolute addresses.  Hierarchical, but absolute, not unlike in absolute URLs.  It's more brittle than in a URL because it is based on counted position, not on labeled hierarchy nodes.  That means insertion and deletion of siblings at every level requires these references to be repaired.  That's scary.
		 
		On the other hand, to use an existing example, xml:id="ct270478544" establishes a *fixed* identifier, but it does not rely on fixed locations.  So wherever a text:change-id="ct270478544" happens to refer to it, the connection is maintained no matter what kind of movement happens on the paths between the two.
		 
		It is true that in the specific case of the ODF 1.2 use of this device, the <text:changed-region> element is referenced from the content where it is applicable, not the reverse.  That seems like a good choice to me, considering that it is the reference from the content that makes examination of the <text:changed-region> of any concern.  This also allows the <text:changed-region> material to be output in front of the content, so it can all be indexed before the in-text references occur in the datastream.  
		 
		Does not the MCT use of these rigid absolute paths require that the document be serialized before the tracking information can be serialized?  And for a consumer presenting the content, is it necessary to find the relevant change-tracking information by some synchronization method?  My concern is that it is impossible to detect when synchronization has been broken.  Everything has to be absolutely perfect and there is no way to touch a change-tracked document without having to adjust all of the tracking locations.  That's a considerable burden.
		 
		I am only addressing the cross-identification approach here.  It appears that ODF CT does this in a more robust way; I don't see why MCT can't be made at least as resilient.  
		 
		I think there does need to be a stretchy way to connect between tracked details and the point of change.  An xml:id ID value and a corresponding IDREF attribute value do this perfectly for XML-modeled persistent document formats.  And this kind of support already has to exist in ODF-based processors simply because of the many ways that cross-referencing is handled by identifiers of some type, including IRIs that refer into package parts by fragment identifiers.  
		 
		 - Dennis
		 
		 

	..snip 

	-- 
	-- -----------------------------------------------------------------
	Robin La Fontaine, Director, DeltaXML Ltd  "Experts in information change"
	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, e-mail: office-collab-unsubscribe@lists.oasis-open.org For additional commands, e-mail: office-collab-help@lists.oasis-open.org