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] OpenDocument lists - my view included are some proposals


Thomas Zander wrote:
> On Wednesday 14 February 2007 15:31, Oliver-Rainer Wittmann - Software 
> engineer - Sun Microsystems Inc wrote:
>> Does my interpretation meets your intentation?
> 
> Yap. Exactly.
> 
>> Ok, I can also support your view on the start values for a list.
>> Repeating: We would define, that each list block can define its own
>> start values via its list style. If a list block doesn't define a
>> start value, the start value of the surrounding list block is used.
> 
> Hmm, that is basically the same proposal in other words, so I still don't 
> agree :)
> When an xml field is not specified it tends to be read as a default value, the 
> value does not change based on the place it is used.
> What you seem to want is that you have a style with a startvalue defined to 
> take the one of the parent list (superior list).
> So;
> <text:list text:style-name="L1">
>    <text:list-item>
>      <text:p>Main Chapter</text:p>
>    </text:list-item>
>    <text:list>
>      <text:list-item*>
>        <text:p>Foo</text:p>
>      </text:list-item>
>    </text:list>
> </text:list>
> And L1 defining level1 to start at, say 5 and leaving the start at level2 
> undefined (attribute not in xml) this will give us;
> 
> 5 Main Chapter
> 5.5 Foo
> 
> That doesn't sound right to me.  If the level2 leaves it undefined then it 
> should be "5.1".   I suggest you come up with another way to do what you seem 
> to want.
> I do have to note that the usecase for this seems very contrived and a user 
> can just as easily set the level 2 start at 5 manually for those corner 
> cases.  Specifically this fails the credo;
>  "Make it easy to do the correct, and possible to do the hard"
> 

Oh, sorry. There is a mis-understanding, because I wasn't clear enough.
Yes, start values are defined for a certain list level with the list 
level definitions of a list style and can't be applied for other list 
levels. I didn't mean, that (e.g.) the start value for list level 1 is 
taken as the start value for list level 2.

My intention was triggered more or less by the following example, when 
different list styles are used inside a list:
<text:list text:style-name="L1">
    <text:list-item>
      <text:p>Main Chapter</text:p>
    </text:list-item>
    <text:list>
      <text:list-item text:style-overide="L2">
        <text:p>Foo</text:p>
      </text:list-item>
    </text:list>
</text:list>

respectively

<text:numbered-paragraph text:style-name="L1" text:list-id="myList1"
    Main Chapter
</text:numbered-paragraph>
<text:numbered-paragraph text:style-name="L2" text:list-id="myList1"
    Foo
</text:numbered-paragraph>

L1 defines that list level 1 starts at 5 and list level 2 starts at 7.
L2 contains a list level definition for list level 2, but doesn't define 
a start value for list level 2.
 From my point of view it would make sense that this should give us:

5. Main chapter
5.7. Foo

In my view L1 is somehow the "leader" of the list. Thus, I came to this 
conclusion.
But, I could also support, that this case gives us:

5. Main chapter
5.1. Foo


>> We have two list blocks on list level 2. Each of these list blocks
>> restarts the counter for the list level 2. These list blocks belongs
>> to list level 2. Restarting the counter for a certain list level means
>> to set its value to the defined start value.
> Yes, agreed. They are technically speaking different (sub) lists. So they 
> start at the beginning.
> 
>>> So you actually think we should have
>>>  1. head
>>>  a.a head 2
>>> if the list-level 2 has a different definition for the level 1?
>> Yes.
> ...
>> I think the user should decide - as I already stated above.
> Fair enough.

Ok.

> 
>>> This just indicates that you should not have used a text:list structure
>>> for the non-continues list, but you should have used numbered-paragraphs
>>> for the 3 list items.
>>> On top of that; your example doesn't actually need the proposed
>>> extention. It would work fine with the current continue. Wouldn't it?
>> I don't think that I will work this the current specification. The
>> current specification only talks about the direct preceding list and
>> that its numbering can be continued. I want to extend this to all
>> preceding lists.
> 
> Yeah, you are probably right about that.
> Still, we invented numbered-paragraphs for exactly the situation you want to 
> solve, so I'm unconvinced about the extention you want to make being needed.
> I'm undecided on this one.
> 
Yes, I also think that numbered-paragraphs are the best for such cases.
My proposal has the intention to assure that both list definitions 
(<text:list> and <text:numbered-paragraph>) are convertible into each other.


Regards, Oliver.


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