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: Example on change-tracking compromise


Dear SC,

Following, you will find an introduction to the design principles of the change-tracking (CT) compromise and examples covering the three use-cases (UC4-6 ) discussed on last OASIS sub-committee (SC) call.

UC 4: Overlapping Style Changes

"This example is similar to UC 1. The word bold-italic is italicized and all the words containing bold are made bold."
Definition of change:

Starting markup:

<text:p>Normal normal bold bold bold-italic bold bold normal normal.</text:p>

Ending markup:

<text:p>Normal normal <text:span style="bold">bold bold <text:span style="bold-italic">bold-italic</text:span> bold bold</text:span> normal normal.</text:p>


Content of "undo.xml":
<changes>
    <style s="1/15" e="1/46" type="bold-off"/>
    <style s="1/25" e="1/36" type="italic-off"/>
</changes>
Description of undo.xml (repeated from previous mail):
The RelaxNG schema and explanation of all XML nodes of the "undo.xml" file (the resulting XML change) will be in a new part of our ODF specification.
The attributes s (start) and e (end) identify components. In case there is only the attribute "s", it is a single component. In case both attributes "s" & "e" are used, it is a selection of multiple components within the component tree (ordered as in XML).
The numbers represent the location of component in the document component tree. Even a single character are taken as a component.
XML based counting starts with 1. For example, the access of the 12th character within the 3rd paragraph of a text document is shown as "3/12". An insertion at this position would place the new component in front of the selected (e.g. 12th character).
(Note: I am uncertain yet if a preceding label specifying the type of component is helpful, e.g. "p3/c12" for 3rd paragraph/12th character. The prefix would be redundant, but is more human readable and might simplify the mapping into internal models, different to the ODF. The label would provide immediately the information without need to look-up in the "content.xml").
The sequence of the change-events is chronological. But change-events might be grouped by further <changes> elements, even creating a tree hierarchy.
For instance the changes of a document (e.g. our specification) can be sorted by an ODF errata version, which is separated by ISO national body issues, separated by issue numbers.

NOTE: Assuming the paragraph of the example is the first component in the document

UC 5: List Edit and Convert to Paragraphs

"This example is similar to the example “Paragraph / list item merging” in the ECT proposal supplement 1. A list item text is edited and the list is converted to regular paragraphs."
Definition of change:
  • Line 1

  • Line 2

  • Line 3

Line 1

Line 2 added

Line 3


Starting markup:

<text:list>

<text:list-item>

<text:p>Line 1</text:p>

</text:list-item>

<text:list-item>

<text:p>Line 2</text:p>

</text:list-item>

<text:list-item>

<text:p>Line 3</text:p>

</text:list-item>

</text:list>

Ending markup:

<text:p>Line 1</text:p>

<text:p>Line 2 added</text:p>

<text:p>Line 3</text:p>



Content of "undo.xml":
<changes>
    <list s="1/1">
        <indent item="3"/>
        <indent item="2"/>
        <indent item="1"/>
    </list>
    <delete s="1/1/2/7" e="1/1/2/13" />
</changes>
Description of undo.xml
(see description of first use case)
NOTES:
  1. Assuming the list of the example is the first component in the document
  2. Nested within a component there are events relevant to the component (e.g. for tables insert-row) and the access is relative to the component root ando no longer to the document tree. (Especially helpful to address a row, column, cells or cell-range address within a table).
  3. As every new event is based on a component tree existing when the event started, the opposite order of indent events would result in an invalid state. Implementors feed-back to change this behavior.

UC 6: Text Frame Modifications

"This example is similar to the example “Table cell merge – multiple” in the ECT proposal supplement 1. The text box is moved, text edited, resized and moved."


Definition of change:
Text Box Example
Starting markup:

<draw:frame … svg:x="1.0in" svg:y="1.0in" svg:width="1.0in" draw:z-index="0">

    <draw:text-box fo:min-height="0.3in">   
        <
text:p>Text box</text:p>
    /draw:text-box
>
<
/draw:frame>
Ending markup:

<draw:frame … svg:x="2.0in" svg:y="2.0in" svg:width="1.5in" draw:z-index="0">

    <draw:text-box fo:min-height="0.3in">
        <
text:p>Text modified box</text:p>
    <
/draw:text-box>
<
/draw:frame>

Content of "undo.xml":
<changes>
    <box s="1/1">
        <seize w="1.0in"/>
        <position x="1.0in" y="1.0in"/>
    </box>
    <delete s="1/1/6">modified <delete>
</changes>
Description of undo.xml
(see description of first use case)
NOTE:
  1. Assuming the text box of the example is the first component in the document 
  2. It is interesting for later Operational Transformation (OT) that the above insert event
    <delete s="1/1/6">modified <insert>
    has the same result as
    <delete s="1/1/5"> modified<insert>
    Future will tell if ODF application might ease OT

Next Steps

What is missing is the ODF XML change description of the events, that should be moved to the ODF spec.
The next step from my point of view would be to provide a prototype definition of an event using a complicate example as insert- or moveColumn.
The initial scope of coverage could be identical to the scope given by the ECT proposal.

Regards,
Svante



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