[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] comparing requirements against Thomas'/David's/Oliver'sproposal
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]