Template of describing a component

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:

    
      
Which ODF XML element marks the beginning of the component

      
What is the minimal XML node set that has to be provided, when
        adding the bare (or default) component

      
What is the maximal XML node set that might belong directly to
        the component (child components not included)

      

      
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.)

      
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