Re: [office] comparingrequirementsagainstThomas'/David's/Oliver'sproposal

[Lars Oppermann <Lars.Oppermann@Sun.COM>]

Florian,

Yes, that is correct. However, while the rendition would be the same, 
the structure is different. Depending on what you intend to represent in 
your document, you might want to use one or the other. Breaking the list 
in two is inly really useful if you want to put something in between.

An application that produces a non-visual rendition (e.g. a talking book 
generator) could make good use of the added structural information, that 
two list-items are part of the same list. Also alternative 
representations for small screens might use that information for 
optimizing the readability of their rendition.

/Lars

Florian Reuter wrote:
> Hi Lars,
> 
> but couldn't you write
> 
> <t:list t:style-name="XY">
>    <t:list-item>...</t:list-item>
>    <t:list-item t:list-item t:style-override="AB">...</t:list-item>
> </t:list>
> 
> as
> 
> <t:list t:style-name="XY" text:id="1">
>    <t:list-item>...</t:list-item>
> </t:list>
> <t:list t:style-name="AB" text:continue-numbering="1">
>    <t:list-item>...</t:list-item>
> </t:list>
> 
> according to Oliver's proposal?
> 
> So the list override is not _needed_, right? 
> 
>> I think the logic which you are trying to apply here is flawed.
> ...
>> Any specification will at least require an algorithm which works according to that specification.
> 
> ;-) I guess we live in two different worlds. I agree that when you design a total new spec/way of numbering this is what
> is most easy to do.
> However I'm forced to live in a world where I have to deal with realities ;-( And one of the realities I have is to deal
> with interop with MS binaries and interop with WW. 
> 
> Where I disagree is that specifications have to require an algorithm in the imperative way as Olivers proposal does. In
> fact in my proposal this is not the case...
> 
> Anyway. It's a TC decision. All I want is that all members understand the implications and that we get a clear
> specification of numbering in ODF1.2.
> 
> ~Florian
> 
> 
> 
>>>> Lars Oppermann <Lars.Oppermann@Sun.COM> 03/28/07 1:28 PM >>>
> Florian,
> 
> I think the logic which you are trying to apply here is flawed. You 
> argue that a certain algorithm cannot adequately implement the proposed 
> specification. You also say, that the specification should not require 
> any specific algorithm.
> 
> Any specification will at least require an algorithm which works 
> according to that specification. A hypothetical inadequate algorithm 
> does not invalidate a proposed specification. The fact that an addition 
> operation does not meet the requirements of the specification for 
> multiplication does not invalidate the specification for multiplication.
> 
> Concerning the examples and your question why a list override is needed 
> if the two fragments yield the same rendition:
> 
> In the given example, all list-items override to the same style. So what 
> is being said is that
> 
> <t:list>
>    <t:list-item t:style-override="XY">...</t:list>
>    <t:list-item t:style-override="XY">...</t:list>
> </t:list>
> 
> should yield the same rendition as:
> 
> <t:list t:style-name="XY">
>    <t:list-item>...</t:list-item>
>    <t:list-item>...</t:list-item>
> </t:list>
> 
> However you need the style specification on the list item if you want to 
> do the following:
> 
> <t:list t:style-name="XY">
>    <t:list-item>...</t:list-item>
>    <t:list-item t:list-item t:style-override="AB">...</t:list-item>
> </t:list>
> 
> 
> 
> Florian Reuter wrote:
>>> This algorithm doesn't consider that a list-item can have an explicit start value.
>> Not quite. It considers the start value. But in a different context. It considers the start-value of L1.level2.
>>
>>> Nevertheless, if this algorithm would be correct and many applications 
>>> has implemented it, this algorithm has to be adjusted, if a new 
>>> feature is introduced to <text:list> lists.
>> This is where I have a different point of view. The spec should be written in a way that it is independent from the
>> internal counter implementation.
>>
>>> Nevertheless, if this algorithm would be correct and many applications 
>>> has implemented it, this algorithm has to be adjusted, if a new 
>>> feature is introduced to <text:list> lists.
>> Nice plan ;-) Update WW 95-2007... 
>> So you say either WW 95-2007 changes their internal way of numbering or it can't read ODF. Interresting ;-)
>>
>>
>>> Can you please consider, my statement, that these two fragments are 
>>> equivalent in ODF1.2 (assuming that the proposal is accepted).
>> Interresting. I always thought that it'll be like 
>> <text:list text:style-name="L1">
>>    <text:list-item><text:p>P1</text:p></text:list-item>
>> </text:list>
>> <text:list text:style-name="L2">
>> <text:list>
>>      <text:list-item><text:p>P2</text:p></text:list-item>
>>      <text:list-item><text:p>P3</text:p></text:list-item>
>> </text:list>
>> </text:list>
>> according to your proposal. 
>> If these fragments would where equal. Why would you need a style-override?
> 
> 
> 


-- 
Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
Software Engineer                                         Nagelsweg 55
Phone: +49 40 23646 959                         20097 Hamburg, Germany
Fax:   +49 40 23646 550                  http://www.sun.com/staroffice