[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]