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 requirements againstThomas'/David's/Oliver's proposal


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>

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.


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.

F3: This requirement is not important according to David and Thomas. So let's skip it.

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.

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.

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.

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. 

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]