Re: [office] Public Comment #210 On Numbering

[Oliver-Rainer Wittmann - Software Engineer - Sun Microsystems<Oliver-Rainer.Wittmann@Sun.COM>]

Hi Dennis,

first let me point you to the approved ODF 1.2 proposal to enhance and
clarify lists, found at
http://www.oasis-open.org/committees/download.php/23418/07-04-05-proposal-lists.odt
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. SITUATION
> 
> 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. POTENTIAL REMEDIES
> 
> 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.

+1
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