[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]