OASIS Open Document Format for Office Applications (OpenDocument) TC

Re: [office] Proposal for lists/numbered paragraphs

  • 1.  Re: [office] Proposal for lists/numbered paragraphs

    Posted 03-26-2003 16:09
    Hi,
    
    David Faure wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    > 
    > On Monday 24 March 2003 16:48, Philip Boutros wrote:
    > 
    >><office:automatic-styles>
    >>   <style:style style:name="P1" style:family="paragraph"
    >>style:parent-style-name="First line indent" style:list-style-name="List
    >>4"/>
    >></office:automatic-styles>
    >>
    >>        <text:unordered-list text:style-name="List 4">
    >>            <text:list-item>
    >>                <text:p text:style-name="P1">One</text:p>
    >>            </text:list-item>
    >>            <text:list-item>
    >>                <text:p text:style-name="P1">Two</text:p>
    >>            </text:list-item>
    >>            <text:list-item>
    >>                <text:p text:style-name="P1">Three</text:p>
    >>            </text:list-item>
    >>        </text:unordered-list>
    >>
    >>
    >>Notice that "List 4" is referenced both by the text:unordered-list and
    >>by the "P1" paragraph style. What if "P1" referenced a different list
    >>style? How would I be required to interpret this? 
    > 
    > 
    > As far as I understand the OO file format, the closest style is that one that 
    > overrides the furthest, so the style named in <text:p> is the one that would be used.
    
    That's correct.
    
    > 
    > If the style for every paragraph specifies P1, then the style associated with
    > the overall list won't be used at all - is this correct, Daniel/Michael?
    
    That's correct as well.
    
    > 
    > 
    >>Since the paragraph style already contains the list style information,
    >>from a rendering standpoint in this example the text:unordered-list is
    >>completely redundant and the text:list-item is simply defining a list
    >>level. List level could be easily done with an attribute (which could
    >>default to 1) producing the following alternative XML. 
    >>
    >><text:p text:style-name="P1">One</text:p>
    >><text:p text:style-name="P1">Two</text:p>
    >><text:p text:style-name="P1">Three</text:p>
    >>
    >>This all seems like a lot of extra syntax just so HTML generation can
    >>eaisly produce <OL> and <LI> tags. 
    > 
    > Not only HTML. Any kind of format that needs structure: XSL, Docbook, ...
    > Formats that don't need structure can easily get rid of it, that's easier than
    > figuring out the structure from a non-structured file - although, well, that's 
    > what word processors have to do when saving, though (figuring out the
    > beginning and end of each list).
    
    
    That's, from my point of view, a very valid argument. Having list 
    elements does not simplify transformations to HTML only, but to many 
    other formats as well, especially to those, that use these standardized 
    formats (HTML, XSL-FO, etc.) as a base. Moreover, the list elements from 
    my point of view represent a structure that in many cases really is 
    present in a document: If one numbers a paragraph in a document using 
    whatever word processor and inserts a new one, the new paragraph gets a 
    number as well, so the intended use of numbered paragarphs is to create 
    list. Taking this into account, I think we should at least not remove 
    the list elements.
    
    However, the problem remains that in word processors, one might create 
    documents that contain numbered paragraphs that are distributed over the 
    whole document and that therfor are no "traditional" lists. The question 
    from my point of view is whether we need a new element for these kind of 
    paragarphs, or whether we consider them a non-stanadard application of 
    lists that does look a little bit strange in the file format, because 
    the structure of the document is strange in fact.
    
    > 
    > Anyway a conclusion of "it's extra syntax, but it's doable and equivalent"
    > (which I agree with), doesn't have the same consequences as a conclusion of
    > "this loses information". That would indeed be a very big problem, but I think
    > we established now that there is no information loss, right?
    
    In fact, there is no loss of information when using lists.
    
    Best regards
    
    Michael
    
    > 
    > - -- 
    > David FAURE, faure@kde.org, sponsored by TrollTech to work on KDE,
    > Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
    > How to write a Makefile.am for KDE/Qt code:
    > http://developer.kde.org/documentation/other/makefile_am_howto.html
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.0.7 (GNU/Linux)
    > 
    > iD8DBQE+f0BC72KcVAmwbhARAiDuAKCQ/NiaLOxNB3vJGkNHT/NpF8pJJwCfdEfg
    > LtAnb429Xq8VWmZcpdN8XTI=
    > =QWZb
    > -----END PGP SIGNATURE-----
    > 
    >