OASIS Open Document Format for Office Applications (OpenDocument) TC

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 

"Dennis E. Hamilton" 

2.1 (my numbers) - I have no evidence that this is caught in the 1.2 changes
from previous versions.  In any case, I am not embarrassed to repeat the
injunction as a reminder that it not be overlooked.

2.2 Obviously, not everything not defined in this particular standard is
"intended" to be application dependent.  There are times when affirmation
through redundancy is powerful, because it moves something from oversight to
"as designed."  I have too many times thought there was only one way to
interpret something and found myself mistaken by reality and surprising
interpretations. Also, we make people work too hard by not providing the
simply explicit versus a kind of catch-me-if-you-can indirectness and
vagueness that has to be resolved by complex study.  Not only does that part
suck, it impeaches everything else we do.  [I do understand the value of
minimizing redundancy as a way to avoid contradiction.  But that demands a
high degree of rigorous attention and careful language as well.]

2.3 Sorry, I dropped a stroke.  What I meant "to be accomplished" was
offering a means for discovery of how a 1.x producer interpreted the feature
under question, so that a 1.2 consumer could come up with the closest match
through use of the 1.2 provisions.  On the call, we were talking about
identifying generator strings and somehow learning which producers applied
which interpretation.  That's the dot I didn't connect.

3. I think the question is whether or not I delimited the situation that is
unsatisfactory for Florian, so he can say exactly what is still missing for
him, or whether there is something in here that would satisfy the problem
from his perspective and concern.  I am not clear what he thinks the TC is
empowered to do here, and I await his response. 

I don't expect the TC to every be in the bug adjudication business, so we
are aligned on that.  Whether vendors would voluntarily account for bugs,
once discovered, so that products could work around the consequence in
legacy documents is an interesting topic.  That probably doesn't require TC
involvement either.   Producers can unilaterally introduce sufficient
details in 

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