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] list-override proposal


Hi Florian,

Florian Reuter wrote:
> Hi Oliver,
> 
> /me is also disappointed that I don't really understand your proposal. However /me has not yet given up ;-)
> 
> Regarding the schema you proposed in the name of Thomas and David I have the following question:
> 
> In order to be backward compatible with ODF1.0/1.1 the list-id would have to be optional I guess. Is this mandatory by accident or by intention?
It's intention. Read thread starting with message 
http://www.oasis-open.org/archives/office/200702/msg00066.html

> 
> The other thing I have problems with is this:
> I assume that adding a list-override to the numbered-paragraph would solve the same problem as the list-id, right?
In my opinion the new proposed attribute list-id also solves the 
problem, that the ODF 1.1 specification doesn't specify, how numbered 
paragraphs form a certain list and thus, how a counter domain is formed 
for numbered paragraphs. See mailinglist thread starting with message 
http://www.oasis-open.org/archives/office/200702/msg00046.html

> 
> So from a practical point of view I consider a list-id to be more harmfull for backward compatibility than a list-override.
> By using a list-override the worst thing which can happen is that the number is formatted wrong.
> By using a list-id the worst thing which can happen is that the actual number is wrong.
> This is why I prefer a list-override.
> 
> So Thomas and you have argued that a list-id is "better" for reasons of "you like it more". And I agree. If we would build ODF1.0 I would agree. However there has been a lot of promise around ODF beeing stable for decades and even centuries.   And I just think that a list-override serves this issue better.
> 
> For example. Let suppose we want to express the following numbered paragraphs
> 1. Par1
> B. Par2
> 3. Par3
> 
> With list-id we would get
> <numbered-paragraph list-id="1" style:name="L1">Par1</numbered-paragraph>
> <numbered-paragraph list-id="1" style:name="L2">Par2</numbered-paragraph>
> <numbered-paragraph list-id="1" style:name="L1">Par3</numbered-paragraph>
> 
> and with list-override we would get
> <numbered-paragraph style:name="L1">Par1</numbered-paragraph>
> <numbered-paragraph style:name="L1" list-override="L2">Par2</numbered-paragraph>
> <numbered-paragraph style:name="L1">Par3</numbered-paragraph>
> 
> Correct?
> 
> So let's look what an ODF1.0/ODF1.1 reader would make of this:
> 
> <numbered-paragraph list-id="1" style:name="L1">Par1</numbered-paragraph>
> <numbered-paragraph list-id="1" style:name="L2">Par2</numbered-paragraph>
> <numbered-paragraph list-id="1" style:name="L1">Par3</numbered-paragraph>
> 
> interpreted by a ODF1.0/ODF1.1 conforming reader would result in
> 1. Par1
> A. Par2 (wrong number, right style)
> 2. Par3 (wrong number, right style)

Why?
The current ODF 1.1 specification doesn't specify that all numbered 
paragraphs, which are applying the same list style form a list.

As I already stated above and the postings in the last weeks, the ODF 
1.1 specification doesn't specify at all, how numbered paragraphs form a 
certain list and thus, how a counter domain is formed for numbered 
paragraphs.

Thus, a ODF 1.1 conforming reader could also produce result:
1. Par1
B. Par2
3. Par3

Another ODF 1.1 conforming reader could produce result:
1. Par1
A. Par2
1. Par3

> 
> and 
> 
> <numbered-paragraph style:name="L1">Par1</numbered-paragraph>
> <numbered-paragraph style:name="L1" list-style-override="L2">Par2</numbered-paragraph>
> <numbered-paragraph style:name="L1">Par3</numbered-paragraph>
> 
> interpreted by a ODF1.0/ODF1.1 conforming reader would result in
> 1. Par1
> 2. Par2 (wrong stlye, right number)
> 3. Par3
> 
> So in on case the style is preserved and in the second case the actual number is preserved. Its just my feeling that the number is more important than the style.
> 
> I'm actually suprised that most of the TC members consider the style as more important than the actual number. I was not aware of this. I honestly always assumed that we had an understanding that the number is more important.
> 
> So under the assumption that
> a) we make the list-id optional and 

Then ODF 1.2 specification will still contain the insufficiency, that it 
doesn't specify, how numbered paragraphs form a certain list and thus, 
how a counter domain is formed for numbered paragraphs.
How do you think, we should solve this insufficiency?
Or do you want that the ODF 1.2 specification should still contain this 
insufficiency?

> b) we really consider backward compatibility with the style to be more important than backward compatibility with the right number
> I consider to give up my objections. Althought I still think that the right number should be more important than the right style ;-)
> 
> ~Florian
> 
>>>> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems <Oliver-Rainer.Wittmann@Sun.COM> 03/09/07 1:55 PM >>>
> Florian Reuter wrote:
>> Here is my proposal for the list-override enhancement.
>>
>> It should also cover all use cases us the "list-id" proposal, so (in my opinion :-)) there is no need for a list-id. In fact I discourage the use of "list-ids" because:
>> * No backward compatibility: A reader which does not understand the text:list-style-override will still be able to correctly number all paragraphs. The only difference would be a different formatting. For example instead of 1. ii. 3. an old reader would generate 1. 2. 3..
>> * Using a list-id approach would cause a serious backward compatibility break, sin The association of list styles with a “counter domain” is usually sufficient. By using a style-override the style of the number formatting can be changed. Splitting this relationship between a list style and a “counter domain” would cause unneeded redundancy, since in the “normal” case the list-id and the style-name had to be emitted.
>> * By introducing a list-id the transformation between text:lists and text:numbered-paragraphs can be quite complicated. This would be a burden for the implementation.
>>
>> I also included some "normative examples" for ODF1.1 lists to avoild from misunderstandings of how lists currently work.
>>
>> ~Florian
> 
> Hi,
> 
> as I told you already on Wednesday, I didn't share your concerns about 
> the existing proposal - see 
> http://lists.oasis-open.org/archives/office/200702/msg00172.html - in 
> your serious given form.
> 
> I also suggested to be more complete and precise in your proposal. 
> Namely state, what exactly is the impact for your proposed 
> text:list-style-override on the <text:list> element and on the 
> <text:numbered-paragraph> element.
> I also think, that introducing the "override" attribute at element 
> <text:list-item> provides much more flexibility, than to introduce it at 
> element <text:list>.
> 
> Additionally, I suggested to include the clarifications (2), (4), (5) 
> and (6), which are given in the existing proposal - see 
> http://lists.oasis-open.org/archives/office/200702/msg00172.html - in a 
> similar form.
> 
> The existing proposal also includes the clarification about the counter 
> domain for numbered paragraphs - see (1) in 
> http://lists.oasis-open.org/archives/office/200702/msg00172.html -, 
> which is currently not clear in the ODF 1.1 specification. See 
> http://www.oasis-open.org/archives/office/200702/msg00046.html and the 
> following thread, which discussed this unclear point in the ODF 1.1 
> specification. The proposed new attribute text:list-id has the elegance 
> to clarify this in ODF 1.2.
> Thus, I suggested, you should include a similar clarification about this 
> in your proposal, too.
> 
> 
> I'm a little bit disappointed that you haven't got considered any of my 
> suggestions, yet.
> I think your proposal in its current state isn't complete enough in 
> order to compare it with the existing one. Thus right now, I don't think 
> your proposal is a true alternative to the existing one.
> 
> Under the assumption, that you consider my suggestions, I want to ask 
> you, if you can again consider the existing proposal and think about it. 
> Please check, if you can support it. It's a compromise, that is 
> supported by most of the TC members.
> 
> 
> Regards, Oliver.
> 



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