[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] comparing requirementsagainst Thomas'/David's/Oliver'sproposal
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. 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 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. > 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 -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]