Re: [office] comparing requirementsagainst Thomas'/David's/Oliver'sproposal

["Florian Reuter" <freuter@novell.com>]

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