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] Public Comment #210 On Numbering

Hi Dennis,

first let me point you to the approved ODF 1.2 proposal to enhance and
clarify lists, found at
on our wiki page http://wiki.oasis-open.org/office/List_of_Proposals

Dennis E. Hamilton wrote:
> On listening to the discussion of this item, it appears that we have
> the following situation.  I want to confirm my understanding of it.
> 1.1 There are situations where list/paragraph numbering have been
> done differently in different ODF 1.0/1.1 implementations, and those
> specifications are not unclear/incomplete in requiring stronger
> agreement.

As far as I know, there are the following errors/defects in
OpenOffice.org 2.x regarding the ODF 1.0/1.1 specification:

- OpenOffice.org 2.x mis-interprets the specification text of attribute
text:continue-numbering - If text:continue-numbering="true",
OpenOffice.org 2.x by mistake continues a list with the same list style,
which is not the preceding list.

- OpenOffice.org 2.x does not support element <text:numbered-paragraph>
completely - <text:numbered-paragraph> elements are only imported as
<text:p> elements.

> 1.2 The current draft of ODF 1.2 is clear.

IMHO, yes. The above mentioned proposal makes ODF 1.2 clear.

> 1.3 There is no guidance on how to take legacy documents of the (1.1)
> kind and consistently upgraded them to (1.2) condition (or even
> round-trip them properly by producing older-version ODF documents?).

There is some guidance regarding <text:numbered-paragraph> - see ODF 1.2
specification committee draft 1

> 2.1 Clearly, we need to make sure that the improvement in ODF 1.2 is
> identified in the section on changes from previous versions.

This is something for the "change" chapter. May be, we should clearly 
state in the corresponding section that we improved the ODF 
specification in this area.

> 2.2 We could acknowledge, in errata for ODF 1.0/1.1, that the
> relevant part of the specification is underspecified and is
> effectively left to be implementation determined.  (This would be
> essentially a confirmation of the consequences of what there is and
> is not specified.)

May be. But, I am not sure that this would help.

> 2.3 There could be an ODF TC technical memorandum on the situation
> with suggested ways for implementations to accomplish this.  The ODF
> 1.2 specification could make a non-normative reference to such a
> memorandum.
> 2.4 There could be a Wiki where the handling of these list/paragraph
> numbering cases that applies for specific generators of versions of
> ODF documents is registered.  This would also need to provide for the
> interesting case of newer generators producing down-level documents
> (e.g., OO.o 3.0.x when configured to save documents as ODF 1.0/1.1,
> resulting in their identification with office:version="1.1").  The
> technical memorandum could also locate the wiki page where this
> material can be located.
> 2.5 We could make a non-normative appendix that identifies where
> these legacy-adjustment practices and similar glitches are addressed.
> I don't think that is a great idea.  I think the place linked in the
> front matter with regard to errata should also find technical
> memoranda, and the various on-line resources, such as the ODF TC
> page, should point out their existence as well.
> 3. IS THAT IT?
> I am not clear what other remedy and guidance can be provided.  Would
> having this situation be handled on-line in some prominent place
> provide the necessary notice and also provide a place where
> implementers could refer people who are having interoperability and
> document upgrade problems in this area?
> I also don't think we can do very much in the 1.2 specification to
> anticipate further situations like this.  One could use provisions
> akin to those of Markup Compatibility and Extensions (MCE, IS
> 29500-3:2008) for separating a rigorous (hence breaking) cleanup from
> what were found to be ambiguously-specified, variously-implemented
> earlier features.  This seals off the tightly-specified feature from
> the found-to-be-ambiguous flavors.  It seem unlikely that such
> feature versioning solves migration from one to the other by itself
> (although it makes absolutely clear where a feature-versioning
> situation is in hand), and technical memoranda providing guidance
> would still be required.

Best regards, Oliver.

Sun Microsystems GmbH    Oliver-Rainer Wittmann
Nagelsweg 55             Software Engineer - OpenOffice.org/StarOffice
20097 Hamburg
Germany                  Fax:   (+49 40) 23 646 955
http://www.sun.de        mailto:oliver-rainer.wittmann@sun.com
Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Oliver-Rainer Wittmann (od) - OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS

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