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


Hi David,

yep. There a bug.

It should be
1. P1
2. P2
C. P3

right?

So you don't consider this to be a requirement. Thats fine with me.

~Florian




>>> David Faure <faure@kde.org> 03/19/07 5:23 PM >>>
> text:numbered-paragraph legacy docs
> Another type of legacy docs which arose from the fact that ODF1.0/ODF1.1
> numbered-paragraphs are not fully specified are ODF fragments of the
> following type 
> <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>
> which are interpreted as
> 1. P1
> 1. P2
> 2. P2
There's a bug there: the text doesn't match the xml (I guess you mean P1/P1/P2).
But I'm also not sure that the numbering would look like 1/1/2, this would be only if L1 
has a start-value, i.e. asks to restart numbering. Otherwise (by default) you would get "1, 2, III" no?
(given that L2 is roman numbering).

> So numbered-paragraphs are treated as if there only exists one counter
> domain at all.
Well.... it was underspecified. And OOo didn't implement it, and KOffice treated them as
if there was one counter domain in between headings.

At this point I don't think -anybody- cares about backwards compatibility for text:numbered-paragraph
[koffice can handle old koffice documents on its own], so let's not make this a requirement.
Let's have a clean spec instead. I thought we had agreed on that so I'm surprised to still see
"compatibility with odf 1.0/1.1 about numbered-paragraphs" in the requirements.

> ODF 1.2 numbering should be independent from an applications counter implementation
> Applications can basically follow several strategies when maintaining the internal counters. Together with
> the text:start-value of the list style the choice of the internal strategy may have a serious impact on the resulting
numbering. 
> The ODF 1.2 numbering should not require a special strategy for an application's counter implementation.

I don't understand this. Are you saying that the spec shouldn't have any normative examples,
so that applications can implement counters whichever way they want? This seems against
all interoperability goals. If the specification has "expected results" in normative examples,
then surely the applications have to choose among the implementation strategies that will
lead to the expected results. Obviously; just like with anything else.

If you mean that one existing implementation shouldn't be the reason for deciding how things
should behave, well I would agree, but this conflicts a little bit with the backwards-compatibility
requirement when old OOo docs have to keep being loadable :)

In short, and to help with the upcoming job on listing the requirements, I suggest:
* to drop the "compatibility with ODF-1.0/1.1" requirement for text:numbered-paragraphs
(but I agree with having it for text:list)
* to drop the "independent from an application's counter implementation" requirement
(or to rephrase it, since its text seems to be a different goal than its title).

David.



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