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 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:
- Assuming the list of the example is the first component in the
document
- 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).
- 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:
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:
- Assuming the text box of the example is the first component in
the document
- 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
|