Re: [office] comparing requirements against Thomas'/David's/Oliver'sproposal

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

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