OpenDocument - Adv Document Collab SC

 View Only
  • 1.  Lists - information overflow

    Posted 02-06-2013 12:19
    The list topic really can cause some headache, but as I started it, allow me to provide an update. I have asked myself, do we need to preserve all list style information provided by a list hierarchy on a paragraph? For instance, on paragraph on the tenth list level in ODF there can be referenced up to eleven different list styles. <text:list text:style-name= L1 >     <text:list-item text:style-override= L2 >         <text:list text:style-name= L3 >             <text:list-item text:style-override= L4 >                 <text:list text:style-name= L5 >                     <text:list-item text:style-override= L6 >                         <text:list text:style-name= L7 >                             <text:list-item text:style-override= L8 >                                 <text:list text:style-name= L9 >                                     <text:list-item text:style-override= L10 >                                         <text:p text:style-name= P1-referencing-to-L11 >Hello list!</text:p>                                     </text:list-item>                                                                </text:list>                             </text:list-item>                         </text:list>                     </text:list-item>                 </text:list>             </text:list-item>         </text:list>     </text:list-item> </text:list> Each may offer a style definition for each of the list level - for instance OpenOffice support 10 list level in the UI - this may result into a maximum of 110 list styles in total, while only 1 is being applicable at the paragraph. (NOTE: In theory the attribute @text:level is not restricted to 10 and may be any arbitrary positive integer. But so does @text:outline-level for heading, still in HTML 5 it can only have 6 levels .) The inverse question is: What do I lose, what is the mandatory required information to provide? For instance, if I only provide the one style being applied, i.e. the style definition of the tenth level first being found in a list style looking in that order: L10, L9, L8, L7, L6, L5, L4, L3, L2, L1, L11. I came to the following conclusion: All template list styles (those from the styles.xml) should be provided by operations, when wiring an ODF document by operations over the net. In case an application allows the choice of existing predefined list styles. (We might even specify default styles in the standard to guarantee a consistent look and feel for ODF documents) Even if there is only one paragraph in the above example, which only uses one list level style of a list style, the complete set of list definition level 1 to 10 needs to be wired gathered from the list hierarchy, otherwise the run-time behavior would differ. For instance if a user expands the list (usually pressing CR after an existing list item, here Hello list! and lowers the list level a new list level style would be applied. Which should be used? In this case the 9th list level style from the above example. Therefore all available list level definition have to be provided by an operation. In other words a normalized form (simplified with the same information set) of the above structure could be: <text:list style= L12 >     <text:list-item>         <text:list>             <text:list-item>                 <text:list>                     <text:list-item>                         <text:list>                             <text:list-item>                                 <text:list>                                     <text:list-item>                                         <text:p>Hello list!</text:p>                                     </text:list-item>                                                               </text:list>                             </text:list-item>                         </text:list>                     </text:list-item>                 </text:list>             </text:list-item>         </text:list>     </text:list-item> </text:list> While the list style name L12 is arbitrary, the style would have gathered all gathered list levels from the previous lists into a single one. Do I miss something? What's your opinion? I am awaiting your feed-back! PS: The above example is highly theoretical, especially as the operations are more likely being used in a real-world collaborating context, but it helped me to understand lists and their operations in general. Best regards, Svante


  • 2.  Re: Lists - information overflow

    Posted 02-07-2013 14:41
    A slight correction: the list level of the example is level 5 not 10, as only 5 text:list ancestor are above the text:p. Still the problem is the same. Second, I thought afterwards it might be helpful to give an example of the list definitions, for instance L1 might explain the following in XML: <text:list-style style:name= L1 >     <text:list-level-style-number text:level= 1 text:style-name= Numbering_20_Symbols style:num-suffix= . style:num-format= i >         <style:list-level-properties text:list-level-position-and-space-mode= label-alignment >             <style:list-level-label-alignment text:label-followed-by= listtab text:list-tab-stop-position= 1cm />         </style:list-level-properties>     </text:list-level-style-number>     <text:list-level-style-number text:level= 2 text:style-name= Numbering_20_Symbols style:num-suffix= . style:num-format= i >         <style:list-level-properties text:list-level-position-and-space-mode= label-alignment >             <style:list-level-label-alignment text:label-followed-by= listtab text:list-tab-stop-position= 2cm />         </style:list-level-properties>     </text:list-level-style-number>     <!-- ... 8 more list levels ... -> </text:list-style> On 06.02.2013 13:18, Svante Schubert wrote: The list topic really can cause some headache, but as I started it, allow me to provide an update. I have asked myself, do we need to preserve all list style information provided by a list hierarchy on a paragraph? For instance, on paragraph on the tenth list level in ODF there can be referenced up to eleven different list styles. <text:list text:style-name= L1 >     <text:list-item text:style-override= L2 >         <text:list text:style-name= L3 >             <text:list-item text:style-override= L4 >                 <text:list text:style-name= L5 >                     <text:list-item text:style-override= L6 >                         <text:list text:style-name= L7 >                             <text:list-item text:style-override= L8 >                                 <text:list text:style-name= L9 >                                     <text:list-item text:style-override= L10 >                                         <text:p text:style-name= P1-referencing-to-L11 >Hello list!</text:p>                                     </text:list-item>                                                                </text:list>                             </text:list-item>                         </text:list>                     </text:list-item>                 </text:list>             </text:list-item>         </text:list>     </text:list-item> </text:list> Each may offer a style definition for each of the list level - for instance OpenOffice support 10 list level in the UI - this may result into a maximum of 110 list styles in total, while only 1 is being applicable at the paragraph. (NOTE: In theory the attribute @text:level is not restricted to 10 and may be any arbitrary positive integer. But so does @text:outline-level for heading, still in HTML 5 it can only have 6 levels .) The inverse question is: What do I lose, what is the mandatory required information to provide? For instance, if I only provide the one style being applied, i.e. the style definition of the tenth level first being found in a list style looking in that order: L10, L9, L8, L7, L6, L5, L4, L3, L2, L1, L11. I came to the following conclusion: All template list styles (those from the styles.xml) should be provided by operations, when wiring an ODF document by operations over the net. In case an application allows the choice of existing predefined list styles. (We might even specify default styles in the standard to guarantee a consistent look and feel for ODF documents) Even if there is only one paragraph in the above example, which only uses one list level style of a list style, the complete set of list definition level 1 to 10 needs to be wired gathered from the list hierarchy, otherwise the run-time behavior would differ. For instance if a user expands the list (usually pressing CR after an existing list item, here Hello list! and lowers the list level a new list level style would be applied. Which should be used? In this case the 9th list level style from the above example. Therefore all available list level definition have to be provided by an operation. In other words a normalized form (simplified with the same information set) of the above structure could be: <text:list style= L12 >     <text:list-item>         <text:list>             <text:list-item>                 <text:list>                     <text:list-item>                         <text:list>                             <text:list-item>                                 <text:list>                                     <text:list-item>                                         <text:p>Hello list!</text:p>                                     </text:list-item>                                                               </text:list>                             </text:list-item>                         </text:list>                     </text:list-item>                 </text:list>             </text:list-item>         </text:list>     </text:list-item> </text:list> While the list style name L12 is arbitrary, the style would have gathered all gathered list levels from the previous lists into a single one. Do I miss something? What's your opinion? I am awaiting your feed-back! PS: The above example is highly theoretical, especially as the operations are more likely being used in a real-world collaborating context, but it helped me to understand lists and their operations in general. Best regards, Svante


  • 3.  Re: [office-collab] Lists - information overflow

    Posted 02-28-2013 09:52
    Hi Svante, you wrote: > I came to the following conclusion: > > 1. All template list styles (those from the styles.xml) should be > provided by operations, when wiring an ODF document by operations > over the net. In case an application allows the choice of existing > predefined list styles. > (We might even specify default styles in the standard to guarantee a > consistent look and feel for ODF documents) > 2. Even if there is only one paragraph in the above example, which only > uses one list level style of a list style, the complete set of list > definition level 1 to 10 needs to be wired gathered from the list > hierarchy, otherwise the run-time behavior would differ. For > instance if a user expands the list (usually pressing CR after an > existing list item, here "Hello list!" and lowers the list level a > new list level style would be applied. Which should be used? In this > case the 9th list level style from the above example. Therefore all > available list level definition have to be provided by an operation. > I wonder if this it yet relevant for the SC task (which is change tracking) - aren't we quickly entering the realm of application runtime behaviour here, that so far the TC has carefully avoided to mandate? Cheers, -- Thorsten Behrens SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Attachment: signature.asc Description: Digital signature


  • 4.  Re: [office-collab] Lists - information overflow

    Posted 02-28-2013 11:29
    Hi Thorsten, On 28.02.2013 10:50, Thorsten Behrens wrote: > Hi Svante, > > you wrote: >> I came to the following conclusion: >> >> 1. All template list styles (those from the styles.xml) should be >> provided by operations, when wiring an ODF document by operations >> over the net. In case an application allows the choice of existing >> predefined list styles. >> (We might even specify default styles in the standard to guarantee a >> consistent look and feel for ODF documents) >> 2. Even if there is only one paragraph in the above example, which only >> uses one list level style of a list style, the complete set of list >> definition level 1 to 10 needs to be wired gathered from the list >> hierarchy, otherwise the run-time behavior would differ. For >> instance if a user expands the list (usually pressing CR after an >> existing list item, here "Hello list!" and lowers the list level a >> new list level style would be applied. Which should be used? In this >> case the 9th list level style from the above example. Therefore all >> available list level definition have to be provided by an operation. >> > I wonder if this it yet relevant for the SC task (which is change > tracking) - aren't we quickly entering the realm of application > runtime behaviour here, that so far the TC has carefully avoided to > mandate? > The tracking of changes is the tracking of run-time behavior. But you are right that the collaboration is by far not as important as change-tracking to us. Still we need to understand what is the XML difference when we edit (e.g. list) during run-time. I use the real-time collaboration as theoretical model, to get a better understanding of the mandatory operations. And certainly the argument: "we never did this before" should not be an argument at all for us, quite the opposite. ;) Let me switch the scenario, imagine an ODF application would only load and save a document with a list as described earlier with level 5 paragraph and 11 list styles associated. What would be the valid serialization for that list? I believe, that the correct way would be to collect all list level styles available and not for instance only use the list style directly around the paragraph and fill up the missing list levels with defaults (e.g. numbering). PS: To ease testing, find a (valid ODF 1.2) test file attached, it is the last list that is the one of interest. Cheers, Svante Attachment: ListStyleResolutionPlusDeepList.odt Description: application/vnd.oasis.opendocument.text