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,

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 visual result with both), but the list-id-table thread shows that there
are differences; 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 paragraphs; it is only specified when we want to restart the numbering. In named styles for paragraphs, start-value 
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 :-)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


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