Template of describing a component

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

When we specify a component - the logical puzzle piece of the document from a user perspective - there are repeating sets of information to be given:

1. Which ODF XML element marks the beginning of the component
2. What is the minimal XML node set that has to be provided, when adding the bare (or default) component
3. What is the maximal XML node set that might belong directly to the component (child components not included)
   
4. What logical operations are usually on the XML node set.
   (NOTE: If all document changes should be tracked - which is not the case for us now, as we focus on the ECT feature set - all XML nodes need to be covered by operations.)
5. How does a defined operation change the XML node set of a component.
   (REMEMBER: A parametrized operation is just a placeholder for an ODF XML change).

In our high-level auxiliary model a component consists of one or more XML nodes. The state of a component is given by its properties, which are in general being mapped to XML attributes.

We should keep in mind, that the component model allows us to abstract from the design decision of the ODF XML model.
The definition of components and their properties is just an intermediate step, as the real importance for change-tracking is not the state, but the state changes represented by operation with parameters (the XML change abbreviation).

For example, although ODF XML differentiate between a paragraph, a heading and a list item, all three of them are based on a paragraph.
As a design suggestion: A paragraph with an outlineLevel property (based on the @text:outline-level attribute) higher than 0 is called a heading.
A paragraph with an indentLevel property (based on the nesting within the text:list/text:list-item element duo) higher than 0 part of an list-item of a list.
Similar to the border style handling of paragraphs, where no border is drawn between paragraphs of the same style, a list label is only drawn at the first paragraph with the same indentLevel.

Therefore the change/transformation of a paragraph to a heading or movement of a paragraph into a a list-item, can be simply archived by property changes on the paragraph component, not by complex delete/insert operation of different foreign components.

Looking forward to discuss this tomorrow,
Svante