Re: [office-collab] draft: specification text for "Insertion of a paragraph"

[Svante Schubert <svante.schubert@gmail.com>]

Hi,

On 16.01.2013 10:40, Oliver-Rainer Wittmann wrote:

Hi,

at [1] you find my draft for the specification text for "Insertion of a
paragraph".
Certain questions are still open to me, especially regarding the "Counting"
in the ODF to identify at certain ODF component resp. ODF element.

[1] https://wiki.oasis-open.org/office/Insertion%20of%20a%20paragraph

As I just wrote to Patrick, it is helpful to map the change-tracking scenario to a real-time collaboration scenario (RTC) to make the requirements for change-tracking (CT) more obvious.

In the very beginning the idea of saving of operations into the ODF XML document, has its origin from the scenario of a user real-time collaborating (RTC) where one was entering a train tunnel loosing connection, but continuing its work and the need to save his changes into the document to synchronize them later to the others. RTC has stricter requirements than CT, but a compatibility is desirable to allow easier expansion of our feature set.

For the future RTC (and the advantage of the ability of easy merge) we are mapping the ODF XML of a document to a component tree to have a common ODF document model that is easier maps on different ODF application models. The idea was to neglecting XML design decisions and focusing on the semantic grouping of components. For instance, it is quite difficult to handle an ODF XPath _expression_ in a HTML browser model with _javascript_, while the reference to a component given by a path being a list of integer is a piece of cake.

During the mapping of the ODF XML to components we have to distinguish between four types of ODF XML elements in a document:

1. Component Roots: Elements marking the root element of a component (e.g. text:p, table:table, ..). These are important, as when a component is inserted on the same level of
   
2. Delimiters: Markers that create groupings of components. (e.g. text:bookmark, text:span, ..)
3. Boilerplate: XML elements that do not have any semantic in the ODF component model (e.g. office:body).
4. User Data: XML elements that represent any user/application provided information, unknown to a specific ODF standard

For paragraphs it is quite easy. Most likely every sibling of text:p is a component.
Our ODF 1.2 schema (i.e. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-schema.rng )  states:

        <choice>
            <ref name="text-h"/>
            <ref name="text-p"/>
            <ref name="text-list"/>
            <ref name="text-numbered-paragraph"/>
            <ref name="table-table"/>
            <ref name="text-section"/>
            <ref name="text-soft-page-break"/>
            <ref name="text-table-of-content"/>
            <ref name="text-illustration-index"/>
            <ref name="text-table-index"/>
            <ref name="text-object-index"/>
            <ref name="text-user-index"/>
            <ref name="text-alphabetical-index"/>
            <ref name="text-bibliography"/>
            <ref name="shape"/>
            <ref name="change-marks"/>
        </choice>

Therefore every element above - aside of change-marks and text-soft-page-break being delimiters - are components.
We need to agree on a default set of elements to be counted as components for ODF 1.3 and to allow a seamless future expansion of support, the creation of a mechanism to state the elements/components being counted/supported.

Does this clarify your question?

Best regard,
Svante