OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Proposal for lists/numbered paragraphs


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]