Public Comment #210 On Numbering

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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.

   1.2 The current draft of ODF 1.2 is 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?).

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.

   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.)  

   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.  

 - Dennis

[PS: I can imagine there being more MCE help if the generator string were a URI that could be bound as a namespace for use in MCE clauses.  That is still too gross a level unless one can talk about that generator's "understanding" of a specific feature by sub-namespacing.  This leads to the potential of documents that are conditional on particular treatment by identified generators.  I think the potential cases of abuse are self-limiting as a practical matter, but this prospect will make many folks very uncomfortable.  I find it more likely that an anticipatory provision of this kind will seem like overkill to the remaining folks.  Although one can imagine an MCE approach to cleaning up certain problems by providing AlternateContent for down-level consumers, it is often completely impractical to expect that much of a document producer.

On the other hand, using generator URIs is a nice accompaniment to documentation of implementation deviations and implementation-specific provisions of a particular implementation, even known bugs, security/safety alerts, and available ugprades, if the generator "namespace" URI is usefully dereferenceable/searchable.  Now that's tempting.]

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org