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 Reuter schrieb:
> Hi Oliver,
> 
>> 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.
> 
But, it doesn't consider attribute text:start-value of a list-item.

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

The ODF specification and the proposal doesn't say anything about a
counter implementation. It only describes, what the output should be.

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

I've thought, we are talking about applications supporting ODF.
And yes, you can't change a released piece of software. But, you can 
not except, that every existing software supports something that comes 
up in the future.

But your mentioned application brings me back to one of my questions:
Can WW 95-2007 handle the following ODF1.0/1.1 fragment?
<text:list text:style-name="L1">
   <text:list-item><text:p>P1</text:p></text:list-item>
   <text:list text:style-name="L2">
     <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>
The result of this ODF1.0/1.1 fragment is the following list:
<start value of L1.level1> P1
   <start value of L2.level2> P2
   <start value of L2.level2 + 1> P3

I have already ask this question in my message 
http://www.oasis-open.org/archives/office/200703/msg00305.html.


Regards, Oliver

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

Can you please be more precise?
What does you thought would be like this?

> If these fragments would
> where equal. Why would you need a style-override?
>
To override the applied list style of a *single* list item without 
breaking the list structure.
E.g., to model the following list:
1. P1
1.1 P2
1.2 P3
1.C P4

<text:list text:style-name="L1">
   <text:list-item><text:p>P1</text:p></text:list-item>
   <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-item text:style-override="L2">
       <text:p>P4</text:p>
     </text:list-item>
   </text:list>
</text:list>


Regards, Oliver.

> 
> ~Florian
> 
> 
>>>> Oliver-Rainer Wittmann - Software engineer - Sun Microsystems
>>>> Inc <Oliver-Rainer.Wittmann@Sun.COM> 03/28/07 11:20 AM
>>>> 
> Hi Florian,
> 
> Yes, I still have problems. I don't know, which is the problematic
>  area, which you have mentioned.
> 
> First, the "simple post-increment" algorithm, which you have given,
>  seems to be wrong. This algorithm doesn't consider that a
> list-item can have an explicit start value. It also doesn't
> consider, that the sub list, which contains paragraphs P2 and P3,
> can have another list style. Think of the following ODF1.0/1.1
> <text:list> list: <text:list text:style-name="L1"> 
> <text:list-item><text:p>P1</text:p></text:list-item> <text:list
> text:style-name="L2"> 
> <text:list-item><text:p>P2</text:p></text:list-item> 
> <text:list-item text:start-value="9"> <text:p>P3</text:p> 
> </text:list-item> </text:list> </text:list>
> 
> 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. Attribute 
> text:style-override is a new feature for <text:list> list, thus you
>  can not expect that all former algorithms, which has handled 
> <text:list> list correct, still work correct with <text:list> list,
>  which contain a new feature.
> 
> I my view, your "simple post-increment" algorithm, assuming that
> it's corrected, works with ODF1.0/1.1 <text:list> list. But in my
> eyes it isn't appropriate (even for ODF1.0/1.1 lists), because the
> ODF1.0/1.1 specification clearly states, that for the first list
> item of a list level the start value of the list level style, which
> is currently applied to the list item is used. This isn't reflected
> in your "simple post-increment" algorithm.
> 
> Still, I don't know, what is the problematic area, which you have 
> mentioned.
> 
> Can you please consider my given example ODF fragments: <text:list
> text:style-name="L1"> 
> <text:list-item><text:p>P1</text:p></text:list-item> <text:list
> text:style-name="L2"> 
> <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>
> 
> <text:list text:style-name="L1"> 
> <text:list-item><text:p>P1</text:p></text:list-item> <text:list> 
> <text:list-item text:style-override="L2"> <text:p>P2</text:p> 
> </text:list-item> <text:list-item text:style-override="L2"> 
> <text:p>P3</text:p> </text:list-item> </text:list> </text:list>
> 
> Can you please consider, my statement, that these two fragments are
>  equivalent in ODF1.2 (assuming that the proposal is accepted).
> 
> Can you please answer my questions of my previous messages - see 
> http://www.oasis-open.org/archives/office/200703/msg00306.html and
>  http://www.oasis-open.org/archives/office/200703/msg00305.html
> 
> 
> Regards, Oliver.
> 
> Florian Reuter wrote:
>> Hi Oliver,
>> 
>> wrt to the clarification you requested in F5.
>> 
>> Lets suppose there are applications which interpret the following
>> ODF fragement <text:list text:style-name="L1"> 
>> <text:list-item><text:p>P1</text:p></text:list-item> <text:list> 
>> <text:list-item text:style-override="L2"> <text:p>P2</text:p> 
>> </text:list-item> <text:list-item text:style-override="L2"> 
>> <text:p>P3</text:p> </text:list-item> </text:list> </text:list> 
>> int the following way: <text:list text:style-name="L1">  {Init:
>> c0:=currentListStyle.level1.startValue;
> c1:=currentListStyle.level2.startValue}
>> <text:list-item>{ print c0++ using formatting of currentListStyle
>> }<text:p>P1</text:p></text:list-item> <text:list> <text:list-item
>> text:style-override="L2"> { print c0, c1++ using formatting of
>> currentListStyle } <text:p>P2</text:p> </text:list-item> 
>> <text:list-item text:style-override="L2"> { print c0, c1++ using
>> formatting of currentListStyle } <text:p>P3</text:p> 
>> </text:list-item> </text:list> </text:list> then you would end up
>> with 1. P1 1.1 P2 1.2 P2 when L1.level1.startValue=1,
>> L1.level2.startValue=1, L2.level2.startValue=10
>> 
>> To get to your interpretation of 1. P1 1.10 P2 1.11 P3 we must
>> use a numbering interpreation like: <text:list
>> text:style-name="L1">  {Init: c0:=undefined; c1:=undefined} 
>> <text:list-item>{ if (c0==undefined)
>> c0:=currentListStyle.level0.startValue else c0++;  print c0 using
>> formatting
> of
>> currentListStyle }<text:p>P1</text:p></text:list-item> 
>> <text:list> <text:list-item text:style-override="L2"> { if
>> (c1==undefined) c1:=currentListStyle.level1.startValue else c1++;
>>  print c0, c1 using formatting of currentListStyle} 
>> <text:p>P2</text:p> </text:list-item> <text:list-item
>> text:style-override="L2"> { if (c1==undefined)
>> c1:=currentListStyle.level1.startValue else c1++; print c0, c1
>> using formatting of currentListStyle } <text:p>P3</text:p> 
>> </text:list-item> </text:list> </text:list>
>> 
>> Since many applications use the simple post-increment semantic of
>> the first sample these applications would not be
> able
>> to currectly interpret the numbering according to your proposal.
>> 
>> Please let me know if there are still problems in understanding.
>> This is a very essential in my point of view.
>> 
>> ~Florian
>> 
>> 



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