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


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]