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]comparing requirementsagainstThomas'/David's/Oliver'sproposal


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



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