OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] my requirements


Hi Florian,

(I'm answering to this mail rather than to the reply to me since you 
have said that the example in your previous post was broken. Not sure if 
you meant the post to me, but this one should be correct in any case).

I can follow to what you write in so far that I do understand that 
different algorithms lead to different results.

I'm actually wondering whether an algorithm that outputs a number before 
evaluating all information that may influence the calculation of that 
number can ever output the correct result.

So, I still do not understand what your requirement is? Is it that the 
calculation of the number shall be independent of any list style 
information? Which actually is the same as to say a list style must not 
specify a start value?

Michael

Florian Reuter wrote:
> Hi David,
> 
>>> The ODF 1.2 numbering should not require a special strategy for an application's counter implementation.
>> Too vague IMHO, or I disagree (details in my previous post).
> 
> As I said --- its kind of hard to explain :-)
> 
> Below is what I wrote to Michael Brauer who also wanted clarification regarding my R5. The key to understanding this is ask when are the counters modified and what start-value information do they have at that time.
> 
> <snip>
> Suppose you have two applications (X) and (Y).
> 
> (X) implements numbering in a post-increment way:
> 
> Get the counter of the level of interrest and output it.
> Then increase the counter or reset it according to the current start-value given at the current style.
> 
> (Y) implements numbering in a pre-increment way:
> 
> Increase the counter of the level of interrest or reset it according to the start-value at the current style
> output the number.
> 
> An application which follows the strategy (X) will then interpret
> <text:numbered-paragraph text:level="1" text:style-name="L1" text:list-id="2"><text:p>P1</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:level="2" text:style-name="L2" text:list-id="2"><text:p>P2</text:p></text:numbered-paragraph>
> <text:numbered-paragraph text:level="2" text:style-name="L2" text:list-id="2"><text:p>P3</text:p></text:numbered-paragraph>
> 
> as
> 1. P1  // level 2 of the counters is reset to 1 according to the value in stlye L1
> 1.1 P2
> 1.2 P3
> 
> whereas an application which follows stategy (Y) will produce
> 1. P1
> 1.10 P2 // level 2 of the counters if reset to 10 according to the value in style L2
> 1.11 P3
> 
> with
> <text:list-style style:name="L1">
> <text:list-level-style-number text:level="1" style:num-format="1" text:start-value="1" text:display-levels="1"/>
> <text:list-level-style-number text:level="2" style:num-format="1" text:start-value="1" text:display-levels="2"/>
> </text:list-style>
> <text:list-style style:name="L2">
> <text:list-level-style-number text:level="1" style:num-format="1" text:start-value="1" text:display-levels="1"/>
> <text:list-level-style-number text:level="2" style:num-format="1" text:start-value="10" text:display-levels="2"/>
> </text:list-style>
> 
> </snip>
> 
> I hope this makes it a little bit clearer. (Sorry that my previous example was broken...).
> 
> ~Florian
> 
> 
>>>> David Faure <faure@kde.org> 03/19/07 8:29 PM >>>
> Hi Florian,
> 
> thanks for this very constructive post. Gives me much food for thought ;)
> 
> On Monday 19 March 2007, Florian Reuter wrote:
>> === R1. Backward compatibility with ODF1.0/ODF1.1 (text:list)===
> No opinion there, KOffice doesn't generate text:lists and has a hard enough time trying to load them the way OOo does...
> 
>> === R2. Backward compatibility with "legacy" ODF docs arose from the fact that ODF1.1 wasn't clearly specified ===
>>
>> The TC has a responsability to for the „legacy“ ODF documents who where created by applications due to the fact the numbering in ODF1.0/ODF1.1 wasn't clearly specified.
> This is where implementation bugs suddenly override the specification or the intent behind the specification, or what would be a clean specification.
> I think this responsibility does not exist. It's the implementation's responsibility to load its own old documents,
> but you can't expect other implementations to do so.
> 
>> === R3. text:numbered-paragraph legacy docs ===
> Doesn't matter, for the same reason (unclear spec
> 
>> === R4. 100% roundtrip fidelity between text:list and text:numbered-paragraph ===
>>
>> The current ODF specification states that
>> <quote>
>> A list in <text:list> representation could be converted into a list in <text:numbered-paragraph> representation and vice versa.
>> </quote>
> Well, it can be converted; but this doesn't mean you get the exact same thing,
> as discussed in the list-id-table thread.
> 
>> The use case derived from that is that there should be 100% roundtrip fidelity when converting between numbered paragraph and text:list.
> No, it doesn't say 100%. The two representations are "somewhat equivalent" (you can
> achieve the same vis; which gives a good reason to have both, even. So I have to ask: *WHY* is
> roundtrip fidelity important on this topic.
> 
>> === R5. ODF 1.2 numbering should be independent from an applications counter implementation ===
>> The ODF 1.2 numbering should not require a special strategy for an application's counter implementation.
> Too vague IMHO, or I disagree (details in my previous post).
> 
>> === R6. Use case for ODF1.2 list-override enhancement ===
>>
>> Changing the number formatting of a text:list is current definetly not possible in ODF1.0/ODF1.1.
>> ODF1xample the encoding of the following sample should be possible in ODF1.2:
>> 1. P1
>> 2. P2
>> 3. P3
>> D. Appendix1
>> E. Appendix2
> 
> Agreed.
> 
>> Oliver's/Thomas'/David's and Michael's proposal contradicts thse requirements in my opinion as state below:
> 
>> === R2. Backward compatibility with "legacy" ODF docs arose from the fact that ODF1.1 wasn't clearly specified ===
>> <text:list style-name="L1" text:continue-numbering="true">
> I don't mind which way this is interpreted, as long as the spec is clear about it.
> If the OOo implementation forces the spec to be very convoluted about this, then I'd rather
> that we break compatibility and specify something clear.
> 
>> === R3. text:numbered-paragraph legacy docs ===
>>
>> According to Oliver's/Thomas'/David's and Michael's proposal the following ODF1.0/ODF1.2 "legacy document"
>> <text:numbered-paragraph text:style-name="L1"><text:p>P1</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:style-name="L1"><text:p>P1</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:style-name="L2"><text:p>P2</text:p></text:numbered-paragraph>
>> is no longer valid, since a text:list-id is required. Nothing is said how document of the above type should be handled.
> 
> Nothing was said before either, and list-id would be only mandatory starting from ODF-1.2,
> so this xml would actually still be valid (when generated by ODF-1.0/1.1).
> We can specify how it should be rendered, or not, I don't mind. list-id clarifies this.
> So I disagree with "no longer valid".
> 
>> === R4. 100% roundtrip fidelity between text:list and text:numbered-paragraph ===
> 
> Isn't needed AFAICS.
> 
>> === R5 [...] rom an applications counter implementation ===
>>
>> Thats a hard one to explain :-)
> See, its name is too vague :)
> Your example is much more precise: it's about the behavior of text:start-value in relation with text:level, or something like that.
> 
>> Basically consider 
>> <text:list-style style:name="L1">
>> <text:list-level-style-number text:level="1" style:num-format="1" text:start-value="1" text:display-levels="1"/>
>> <text:list-level-style-number text:level="2" style:num-format="1" text:start-value="1" text:display-levels="2"/>
>> </text:list-style>
>>
>> <text:list-style style:name="L2">
>> <text:list-level-style-number text:level="1" style:num-format="1" text:start-value="1" text:display-levels="1"/>
>> <text:list-level-style-number text:level="2" style:num-format="1" text:start-value="10" text:display-levels="2"/>
>> </text:list-style>
>>
>> then an application can interpret
>> <text:numbered-paragraph text:level="1" text:style-name="L2" text:list-id="2"><text:p>P1</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:level="2" text:style-name="L1" text:list-id="2"><text:p>P2</text:p></text:numbered-paragraph>
>> <text:numbered-paragraph text:level="2" text:style-name="L2" text:list-id="2"><text:p>P3</text:p></text:numbered-paragraph>
>>
>> as
>>
>> 1 P1
>> 1.1 P2
>> 1.1 P3
>>
>> 1 P1
>> 1.10 P2
>> 1.11 P3
>>
>> 1 P1
>> 1.10 P2
>> 1.2 P3
> 
> I get this in kword:
> 1. P1
> 1.1. P2
> 1.10. P3
> 
> because
> * when parsing P2, we're looking at level 2 of L1, which has start value=1. Why would someone get 1.10 for P2? I don't get it.
> * when parsing P3, we're looking at level 2 of L2, which has start-value=10, meaning "restart the counter at 10".
> 
> And yes, if I add a P4 which is just like P3, I get 1.10. again.  text:start-value is usually not specified in automatic styles
> for lue 
> of course means the start value, for the first item in the list, but from what I could see (from the text:list in OOo behavior), 
> start-value on a paragraph's own style really means restart now. To be double-checked, but I gotta go now ;)
> 
>> depending on when the start-value is set. Basically because applications can follow a pre- or post increment strategy here.
> I don't understand what you mean by pre- or post- there. But for sure we need to specify this, so that all
> implementations agree...
> 
>> Oliver's/Thomas'/David's and Michael's demand that the outcome is
>> 1 P1
>> 1.10 P2
>> 1.11 P3
>>
>> however WW will make
>> 1 P1
>> 1.1 P2
>> 1.1 P3
>>
>> out of it, because they use a post increment strategy.
>>
>> This is the reason why I permitted the olverloading of text:start-value in a number style in my proposal.
>>
>> I think the text:restart-at feature should be used instead.
> There is no restart-at, is there? At least not in ODF-1.1. But I agree that it would have been a better name
> than start-value when it really means "restart now". However you're the one who wants to preserve
> compatibility :-)
> 


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