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: GCT delta:merge and paragraphs


Hi,
  I've been considering paragraph deletion and merging in the context of the GCT. In particular, the abiword implementation and how to track document changes in the data model to allow simpler IO paths. I would imagine the abstract details to be of interest to others, especially corner cases which I've not considered yet, thus this email.

Consider an implementation of the GCT which uses metadata to explicitly track the cases when a paragraph has its start and end deleted. Such a case might call for merging two paragraphs using a
delta:merge, possibly with intermediate content deleted.

It seems that tracking such paragraph merges is best to be performed at the time of content deletion. So the user has a selection in the document and presses the delete key, the program then works out the best response to tracking this in its internal data model.

I am thinking that the end of paragraph deleted marker associated with a paragraph in some way, para-end-deleted is set to true if the deletion of the selection can coalesce the next object at the same document scope:

* this is the case if deleting from a para to another para

* this is the case if deleting from a para through an entire table to another para

* this is NOT the case if deleting from a para into an image (draw:frame). In this case the para content to its end is deleted and the image is wrapped in delta:removed-content.

* this is NOT the case if deleting from a para to a para in a table or to a para in another cell of this or another table. In this case starting with para1, para2...paran, tableA, ... celly If the selection extends from ra1 through into celly then The content of para1 "ra1" is deleted with delta:removed-content. para2...paran are enclosed in delta:removed-content to be deleted. Each cell in the selection which from tableA is handled as a subdocument.


When in a table cell, deletion is treated as though it operates on a subdocument:

* The first and last paragraph of the cell can not have their start/end of paragraph deleted markers set to true.

* As an example, if a cell has three paragraphs in it and is entirely contained in the selection to be deleted then it might be delta:merged to a single paragraph, or perhaps since the whole cell content is deleted the old content might be wrapped in a delta:removed-content and a fresh text:p inserted at this change-id.

Another case, if the selection starts from a table cellx and extends beyond that table, including many top level paragraphs (p4,5,6) and into another subsequent table to celly. One would like to contain the paragraphs (p4,5,6) in a single <delta:removed-content> element rather than trying to start a delta:merge on them.

To handle the outright deletion case for p4,5,6 the paragraph might also have metadata with a removed-content=change-id. When such a paragraph is encountered during a save a single delta:removed-content can be emitted to contain this and contiguous subsequent paragraphs with a deleted change-id that is the same value.

A similar para-start-deleted tag might be set to true if this para is in the selection and the previous para is contained in the selection and has para-end-deleted = true. The paragraphs must be at the same document level. For example, in the same table cell or at top level.

I was throwing around table cells. Deletion across a cell boundary either implies deletion of the end content in one cell and the start content in the next or a cell merge. The later operation is normally
performed explicitly through a menu selection.


Considering each table cell as a subdocument does raise the question of table cell merge and paragraphs. The case of table cell merge seems to give this markup, starting at an original document fragment:

<table:table-row>
  <table:table-cell table:style-name="Table1.A1" >
    <text:p text:style-name="Table_20_Contents">Merged cell</text:p>
  </table:table-cell>
  <table:table-cell table:style-name="Table1.B1" >
    <text:p text:style-name="Table_20_ContentsA">c2</text:p>
    <text:p text:style-name="Table_20_ContentsB">c2p2</text:p>
  </table:table-cell>
  <table:table-cell table:style-name="Table1.C1" >
    <text:p text:style-name="Table_20_Contents">c3</text:p>
  </table:table-cell>
</table:table-row>

The following ODT fragment will result after merging A1 with B1. Note that there are some newlines in the below for readability which will need to be removed as to not alter the document content.

Looking bottom up, the old cell c2 is wrapped in a delta:removed-content to remove it. The text:p content that comprises cell2 is effectively moved to the first cell. So the old text:p
elements in cell2 each contain a delta:move-id to track that.

Perhaps the table cell itself might have a move-id attached so things could reference it instead of the subelement. IMHO it would seem nicer to reference the old identical element though, so the new text:p move-idref's directly to the old text:p rather than a parent of the old element.

The table:covered-table-cell is inserted-with-content to mark the old cell location. The new text:p in the first table cell contains the old content of cell2 with idrefs to the old content. As there were two text:p in the old cell2 then there are two new text:p in cell1, each with a move-idref to its respective old text:p.

The first table cell also has an ac:change on its table:number-columns-spanned attribute.

<table:table-row>
  <table:table-cell table:style-name="Table1.A1" 
      ac:change001="2,insert,table:number-columns-spanned" 
      table:number-columns-spanned="2" >
    <text:p text:style-name="Table_20_Contents">Merged cell</text:p>
    <text:p 
       delta:insertion-type="insert-with-content" 
       delta:move-idref="mv33">
       c2
    </text:p>
    <text:p 
       delta:insertion-type="insert-with-content" 
       delta:move-idref="mv34">
       c2p2
    </text:p>
  </table:table-cell>
  <table:covered-table-cell 
     delta:insertion-type="insert-with-content" 
     delta:insertion-change-idref="2"/>
  <delta:removed-content delta:removal-change-idref="2">
    <table:table-cell table:style-name="Table1.B1">
      <text:p text:style-name="Table_20_ContentsA" delta:move-id="mv33">c2</text:p>
      <text:p text:style-name="Table_20_ContentsB" delta:move-id="mv34">c2p2</text:p>
    </table:table-cell>
  </delta:removed-content>
  <table:table-cell table:style-name="Table1.C1" >
    <text:p text:style-name="Table_20_Contents">c3</text:p>
  </table:table-cell>
</table:table-row>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]