[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] comparing requirements againstThomas'/David's/Oliver'sproposal
Hi Florian, please see my comments and questions inline. Regards, Oliver. Florian Reuter wrote: > Hi Michael, > > === wrt. to questions regarding F1 === > > We're talking about b). > >> What is with a). Is my assumption correct that you believe this >> requirement is met? > >> What is the case for an ODF 1.2 document that does not use the new the >> text:continue-list attribute, but only attributes that ODF 1.1 actually >> supports? Will it be displayed correctly in your opinion? > > This is very hard to state, since everytime I came up with an example I was told that ODF1.0/ODF1.1 isn't clear about > this. This is where my F2 requirement comes from. > > So when I understood correctly you once summarized in a TC meeting that numbered-paragraph are not specified and that > text:list are not specified when they are split. > > So you concluded that F1) is never an issue for numbered-paragraphs, since they where not specified at all. > You also conluded that F1) is never an issue for text:list, since they also have specification holes. > I didn't know any "specification holes" for text:list in the ODF1.1. I think there is some stuff that can be stated clearer, but I didn't see any of these "holes" Can you please name the "holes", which exist in your view of the ODF1.1? > Regarding your question: >> Will it be displayed correctly in your opinion? > > No. It won't be displayed correctly in my opinion. However that would mean arguing about what ODF1.0/ODF1.1 actually > meant. We decided not to do this. > So the revised answer is: I have no idea, since it is totally unclear to me what ODF!.0/ODF1.1 says. The only thing I > can do is to look at applications and their interpretations. But that's req F2. > > === wrt. to questions regarding F4 === > >> So, can you please explain to me why you think a screen reader would come to a different result. > > I guess the OOo screen reader will read whats displayed and thus the statement "it looks the same" is true. However > readers which are not build upon the layout will come to a different result. > The concern came into my mind when reading the HTML spec. There is a sample regarding tables and screen reader and the > screen reader here clearly operated on the XML structure. > > Basically (F4) goes far beyond screen readers. It demands that there is exactly one list concept in ODF. Which means > that applications must not implement two different list concepts. And the list representations should be mapable 100%. > > Patrick for example was so kind to summarize this for me: > http://www.oasis-open.org/archives/office/200703/msg00223.html. > > So when rethinking the while ODF1.2 lists this is a very fundamental requirement for me. > > The are two ways to look at it: > a) The lists share the same concept but have different rpresentations. > b) The lists have different concepts but are somehow convertable into each other. > > I guess this is a TC decision, whether the TC want's a) or b). > I clearly want a), but there other TC members see b) as sufficient. > > === wrt. to questions regarding F5 === > >> I have to admit that I don't understand this. Why does it make a >> difference whether the start value is specified by the list style or the >> item itself. > Right. With Olivers proposal there are two ways to chance the counter of a list: > a) using the start value specified by the list style > b) using the start value specified by the list item > In my view these two ways already exist in the ODF1.1 specification. As I tried to illustrate in my previous post - see http://www.oasis-open.org/archives/office/200703/msg00306.html > As a matter of fact a) causes problems wrt to my req F5. So I demand that we specify that we only offer b) to change the > start value in ODF1.2. Can you please name these problems? > >> The <text:list-item> has already a text:start-value. So you >> can map the start value from the style to the list item if an >> implementation does not support start values for list styles, can't you? > > This clearly changes the structure of the list. If the TCs view to lists is > b) The lists have different concepts but are somehow convertable into each other. > then yes --- maybe you can map into each other. > > However if the TC views lists in the ways that > a) The lists share the same concept but have different rpresentations. > then this is no option, since the 100% deterministic roundtrip is not given. > > > ~Florian > > >>>> Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM> 03/27/07 8:32 AM >>> > Hi Florian, > > 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> >> >> 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. > > Can you please clarify that: > > I asked you some time ago how to interpret this requirement by asking: > > "Does it have to apply if you > a) load an ODF 1.1 doc into an ODF 1.2 application, or > b) load an ODF 1.2 doc into an ODF 1.1 application, or > c) both" > > Your answer was: > > "Clearly a). And b) if its technical possible." > > The example you provide is an ODF 1.2 document, since it has the > text:continue-list attribute, which did not exist in ODF 1.1. So we are > talking about b) here only. Correct? > > What is with a). Is my assumption correct that you believe this > requirement is met? > > What is the case for an ODF 1.2 document that does not use the new the > text:continue-list attribute, but only attributes that ODF 1.1 actually > supports? Will it be displayed correctly in your opinion? > >> 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 > > I assume it is an oversight that you did not remove my name here:-) > >> <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. > > Can you please clarify that. If I look at the initial list and the > resulting list, then I don't see a structural difference. In both cases, > we have a list, with four items on the first level. > > The only thing that changed is the way the styles are assigned, but even > there, it seems to me that the styles that are assigned actually are the > same. So, can you please explain to me why you think a screen reader > would 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. > > I have to admit that I don't understand this. Why does it make a > difference whether the start value is specified by the list style or the > item itself. The <text:list-item> has already a text:start-value. So you > can map the start value from the style to the list item if an > implementation does not support start values for list styles, can't you? > >> Again: my only solution to this is to state that text:start-value can not be overwritten by a list-override. >> >> ~Florian > > Best regards > > Michael
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]