[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] comparingrequirements againstThomas'/David's/Oliver'sproposal
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.
> 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?
~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
>
>
>>>> Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems <Oliver-Rainer.Wittmann@Sun.COM> 03/27/07 2:14 PM >>>
> Dear TC members,
>
> Florian Reuter wrote:
>> Dear TC,
>>
>> as discussed in the last TC meeting here are my main objective wrt. to Oliver's/Thomas' proposal:
>>
>> F1:
>> I'm concerned about ODF1.2 docs in ODF1.1 applications. So concider the following ODF1.2 fragment according to
>> Oliver's/Thomas' proposal:
>> <text:list style-name="L1" text:id="id1_1" >
>> <text:list-item><text:p>P1</text:p></text:list-item>
>> <text:list-item><text:p>P2</text:p></text:list-item>
>> </text:list>
>> <text:list style-name="L1" text:id="id1_2" >
>> <text:list-item><text:p>P3</text:p></text:list-item>
>> <text:list-item><text:p>P4</text:p></text:list-item>
>> </text:list>
>> <text:list style-name="L3" text:id="id1_3" text:continue-list="id1_1" text:continue-numbering="true">
>> <text:list-item><text:p>P5</text:p></text:list-item>
>> <text:list-item><text:p>P6</text:p></text:list-item>
>> </text:list>
>>
> Some minor remarks to the given ODF1.2 fragment:
> - It is stated in the proposal, that attribute text:continue-number and
> new attribute text:continue-list should be used mutual exclusive and
> that attribute text:continue-list "wins over" text:continue-numbering.
> Thus, attribute text:continue-numbering should be dropped from the given
> ODF1.2 fragment and this will not change the ODF1.2 fragment.
> - Attribute text:id is optional for element <text:list>. Because the
> second and the third list in the given ODF1.2 fragment aren't
> referenced, its text:id attributes can be dropped.
>
>> It will be interpreted as
>> 1. P1
>> 2. P2
>> A. P3
>> B. P4
>> iii. P5
>> iv. P6
>> according to Oliver's/Thomas' proposal; but according to ODF1.0/ODF1.1 this will be interpreted as
>> 1. P1
>> 2. P2
>> A. P3
>> B. P4
>> i. P1
>> ii. P2
>> since the text:id and the text:continue-list attributes will be skipped.
>>
>> So we get a different numbering of ODF1.2 doc in ODF1.0/ODF1.1 conforming apps.
>>
> I agree to this evaluation.
> The reason, that this ODF1.2 fragment couldn't be interpreted correct in
> a ODF1.0/ODF1.1 supporting application is, that this ODF1.2 fragment
> uses a new feature of ODF1.2 - namely attribute text:continue-list.
>
> In my view this doesn't hurt this part of backward compatibility,
> because in general a new feature in ODF1.2 can't by correctly
> interpreted by ODF1.0/ODF1.1 supporting applications.
>
>> F2: We agreed in the TC call that Oliver's/Thomas' proposal does not meet this req. We agreed that we have to decide
>> whether this is important or not as a TC.
>>
> I think there wasn't an agreement in the TC call that the requirement
> isn't meet. I my eyes I only repeat, what I have stated in my evaluation
> of the requirements against the proposal:
> <cite>
> The proposal doesn't cover this requirement.
> In my opinion, the ODF 1.2 specification doesn't have to take care about
> ODF 1.0/1.1 documents, which are mis-interpreted or wrong interpreted by
> a certain application. Thus, I don't think, that this requirement has to
> be fulfilled.
> The given example in the requirement is in my view a defect - the
> application interprets the given XML fragment wrong. This defect has to
> be fixed in the application, but *not* in the ODF 1.2 specification.
> </cite>
> I still hold this statement. Thus for me, this requirement can be
> skipped as requirement F3 is skipped.
>
>
>> F3: This requirement is not important according to David and Thomas. So let's skip it.
>
> I agree to skip this requirement.
>
>> F4: This requirement is not met by Oliver's/Thomas' proposal since the roundtrip is not deterministic:
>> According to Oliver's/Thomas'/David's and Michael's proposal the following ODF fragment
>> <text:list text:style-name="L1">
>> <text:list-item text:list-override="L2"><text:p>P1</text:p></text:list-item>
>> <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:p>P4</text:p></text:list-item>
>> </test:list>
>>
>> would map into
>>
>> <text:numbered-paragraph text:list-id="id1" text:style-name="L2"><text:p>P1</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:list-id="id1" text:style-name="L1"><text:p>P2</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:list-id="id1" text:style-name="L1"><text:p>P3</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:list-id="id1" text:style-name="L1"><text:p>P4</text:p></text:numbered-paragraph>
>>
>> which then would map back to
>>
>> <text:list text:style-name="L2">
>> <text:list-item><text:p>P1</text:p></text:list-item>
>> <text:list-item text:list-override="L1"><text:p>P2</text:p></text:list-item>
>> <text:list-item text:list-override="L1"><text:p>P3</text:p></text:list-item>
>> <text:list-item text:list-override="L1"><text:p>P4</text:p></text:list-item>
>> </text:list>
>>
>> I agree to Davids comment that they will "look the same". But the structure is different and e.g. a screen reader
will
>> come to a different result.
>
> For me, such a proposed 100% fidelity isn't needed, as I already stated
> in my evaluation of the requirements against the proposal and I tried to
> express this my requirement O10.
>
> In my view the the original list and the resulting are equal:
> - They have the same structure - every list item is in the same position
> as in the original list.
> - The same list styles are applied to the same list items.
>
>> F5:
>> For me it is important that list definitions are declarative. No matter what strategy you follow internally handling
>> counter in your app you should come to the same conclusion.
>>
> I support this statement.
>
>> The problematic area for me is that text:start-value in the style together with the list-override handling.
>>
>> I believe that a text:start-value should not be able to be overwritten, since this has implication when an
application
>> does this.
>>
> I can't follow your interpretation.
>
> For me it is clearly stated in the ODF1.1 specification, that:
> - the start value of the list level style of a list style specifies the
> number of the first list item of the corresponding list level.
>
> Thus, for the following ODF1.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 number for the first list item on list level 2 - namely paragraph P2
> - are the start value given a the list level style for list level 2 of
> list style L2.
>
> For me the above given ODF1.1 fragment is equivalent to the following
> ODF1.2 fragment:
> <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>
> Thus, for this list the number of list item P2 should be the same -
> namely the start value of L2
>
> Thus, I don't know how the handling of the start value of the list level
> style is problematic with the proposed list-style-override feature in
> the proposal.
>
> Can you please point me to the problematic area?
> I think, I didn't understand your view.
>
> Currently, I didn't see any problematic area in the proposal with this
> requirement.
>
>> E.g. WW does update the counter in a pre-increment way. Thus WW will not be able to handle the current idea in
>> Oliver's/Thomas' proposal how text:start-value together with list-overrride are handled.
>
> Does this mean that Microsoft Word isn't be able to handle the above
> given ODF1.1 fragment?
>
>> Again: my only solution to this is to state that text:start-value can not be overwritten by a list-override.
>>
>> ~Florian
>>
>>
>>
>>>>> Oliver-Rainer Wittmann - Software engineer - Sun Microsystems Inc <Oliver-Rainer.Wittmann@Sun.COM> 03/22/07 9:28
AM
>>>>>
>> Dear TC members,
>>
>> following is my view on the proposal from Thomas, David and me - see
>> http://www.oasis-open.org/archives/office/200703/msg00237.html -
>> considering the given requirements from Florian, Michael, Thomas and
>> myself:
>>
>> ad F1:
>> The proposal meets this requirement for <text:list> lists. Because ODF
>> 1.0/1.1 doesn't specify how <text:numbered-paragraph> lists are formed
>> and thus, how they are numbered, no statement can be made here.
>>
>> I disagree to Florian's statement, given in
>> http://www.oasis-open.org/archives/office/200703/msg00216.html, that
>> the proposal doesn't meet the requirement, because the given ODF
>> 1.0/1.1 XML fragment doesn't conform to ODF 1.0/1.1. It contains
>> attributes text:id and text:continue-list, which doesn't exist in ODF
>> 1.0/1.1
>>
>> ad F2:
>> The proposal doesn't cover this requirement.
>> In my opinion, the ODF 1.2 specification doesn't have to take care
>> about ODF 1.0/1.1 documents, which are mis-interpreted or wrong
>> interpreted by a certain application. Thus, I don't think, that this
>> requirement has to be fulfilled.
>> The given example in the requirement is in my view a defect - the
>> application interprets the given XML fragment wrong. This defect has
>> to be fixed in the application, but *not* in the ODF 1.2 specification
>>
>> ad F3:
>> The proposal partly covers this requirement.
>> It makes a proposal, how <text:numbered-paragraph> items should be
>> handled - see point (1) in the proposal. Because the ODF 1.0/1.1
>> doesn't specify how <text:numbered-paragraph> lists are formen and
>> numbered, any interpretation is somehow correct. Thus, I think the ODF
>> 1.2 specification doesn't have to take care about this. Thus, I don't
>> think, that this requirement has to be fulfilled.
>>
>> ad F4:
>> The proposal meets the statement, given in the ODF 1.0/1.1
>> specification about the conversion from <text:list> lists into
>> <text:numbered-paragraph> lists and vice versa. But, it doesn't
>> interprets this statement in such a strict way, as Florian did.
>> I don't think, that a roundtrip conversion has to create 100% the same
>> XML fragment. For me, the roundtrip conversion has to create
>> equivalent XML fragments. In my view the XML fragments, given in
>> Florian's posting
>> http://www.oasis-open.org/archives/office/200703/msg00216.html are
>> equivalent.
>>
>> ad F5:
>> First, I don't know, if I understand this requirement correct.
>>
>> I think I can support this requirement as it is posted and think that
>> the proposal doesn't violate it.
>> But, the given examples confuses me. In my view an application can
>> decide how it implements the counter. But, the behaviour of this
>> implementation is given by the ODF 1.0/1.1 specification. In my view,
>> the ODF 1.0/1.1 states that the list style, which is applied to the
>> first list item of a certain list level can provide the start value
>> for this list level. Thus, regardless of the counter implementation,
>> the number of the first list item of a certain level equals this start
>> value as long as the list item itself doesn't provide a start value.
>> This, I think, isn't violated by the proposal.
>>
>> ad F6:
>> The proposal meets this requirement.
>>
>> ad M1:
>> I think the proposal meets this requirement.
>>
>> ad O1, O2, O3, O4, O8, O9 (requirements O5, O6 and O7 doesn't exist):
>> The proposal meets these requirements.
>>
>> ad O10:
>> This requirement is comparable this requirement F4, but it doesn't
>> demand, that a roundtrip conversion produces the same XML fragment.
>> The proposal meets this requirement.
>>
>> ad T1, T2, T3, T4, T5:
>> The proposal meets these requirements.
>>
>>
>> Regards, Oliver.
>>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]