RE: [office-collab] Let's Keep the Cases Straight: What ODF? has already

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

After all of the emphasis in the ECT proposal that this is just to illustrate a direction that can be taken, and it remains to be determined what the appropriate granularity is (where there is already not any, presumably), why are we making these detail level comparisons as if that is a specific detail of the ECT proposal?

Furthermore, what ODF? already does is not factored in.  The ECT proposal does not dig into ODF?, as far as I can tell, but if there is already ODF? attention to the particular case, that is what ECT should certainly take as a point of departure.

It is already the case that <text:p> being at the top level is not a condition.  Note that <text:list-item> allows, in its children, any number of <text:h>, <text:p> and <text:list> elements, so it is highly recursive.   This is completely illustrated where I show exactly what Libre Office 3.3.2 does (along with a bug) in my "Analysis of Current ODF Deletion Tracking Upload":
http://www.oasis-open.org/committees/document.php?document_id=41714

 (Although the paragraph following the list is top-level in the example I extracted from the LO 3.3.2 document, I could have arranged for all of them to be nested down in some higher-level structure.)

If you look up the change-marks pattern in the schema, or check on the definitions in the ODF 1.2 specifications for <text:change>, <text:change-start>, and <text:change-end> you'll see that these three markers are legitimate elements wherever paragraph-content, text-content, and header-footer content are allowed.  In short, these three elements, one for showing where a deletion restore point is, one for showing where an insertion starts, another for where an insertion ends, can appear as element children of any of the following elements, to name a few:  <text:a>, <draw:textbox>, <text:h>, <text:p>, <text:meta>, <text:meta-field>, <text:span>, <text:section>, <text:note-body>, <text:ruby-base>, and <office:change-info>.  There is no limitation on the context of these elements other than prescribed by the schema.   I have no idea what it means to say code paths would have to be duplicated in these cases.   That seems to have no bearing on how it works in practice.

To make life even more exciting, change-mark elements are also permitted as element children of <text:index-body> and <text:index-title>, which means in every form of index in ODF 1.2 (TOC, list of figures, etc.).

In regard to what Andreas asked, ODF? already allows the change marks in <table:table-cell> and <table:covered-table-cell>.  However, an <office:spreadsheet> and its <table:tracked-changes> does not allow for <text:tracked-changes> so those marks are allowed but not meaningful in a <table:table-cell> of a spreadsheet <table:table> (except possibly under an obscure embedded-spreadsheet edge case).  This is clearly something to be addressed in extending coverage for change-tracking in ODF.


 - Dennis

-----Original Message-----
From: monkeyiq [mailto:monkeyiq@gmail.com] 
Sent: Sunday, April 24, 2011 17:17
To: dennis.hamilton@acm.org
Cc: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Let's Keep the Cases Straight

Hi,
  On page 17 of the extended proposal the example shows the entire draw:frame replaced for any change. On the other hand, reading the GCT proposal as it stands one would implement atomic changes such as 6.3.2 for style modifications to a caption: 
<text:span delta:insertion-type='insert-around-content' ...>

  So the view in this particular example is founded on the proposals themselves. Stepping back from the ECT/GCT comparison, I think the larger trap is to force context dependant processing on common elements such as text:p.

  In abiword, and I'd imagine in many other applications, the load path for ODF uses the same code to turn text:p elements and their children into the internal objects that the application uses to represent the document. Frank Meies has commented that OOo uses this same scheme where all text:p use the same codepath. 

  The context dependant processing of text:p means that such code paths would have to be duplicated; one for text:p elements at top level, and another for text:p elements buried inside a bucket.


On Sun, 2011-04-24 at 14:34 -0700, Dennis E. Hamilton wrote:
> I notice that there is a tendency to view whatever already happens 
> using the ODF 1.x change tracking as part of ECT and that GCT escapes 
> it.
...
> -----Original Message-----
> From: monkeyiq [mailto:monkeyiq@gmail.com]
> Sent: Sunday, April 24, 2011 01:30
> To: Frank Meies
> Cc: office-collab@lists.oasis-open.org
> Subject: Re: [office-collab] Suggestions for moving forward to resolve 
> issues
> 
> On Fri, 2011-04-22 at 12:55 +0200, Frank Meies wrote:
> > That's what OOo currently does. There is no difference (neither in 
> > the generated xml nor in the internal structures) if you change the 
> > caption text:p or any other paragraph in the document.
> 
> So in this particular case, the ECT as it stands is actually a fair bit harder to implement than the GCT. The ECT requiring two very different IO paths depending on context.
> 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> 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
> 



---------------------------------------------------------------------
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