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

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 03/16/2009 
12:24:40 PM:

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

I believe this has been done.

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

Obviously anything that is not defined in the standard is 
application-dependent.  The criteria for determining whether something 
goes into Approved Errata should, IMHO, be set somewhat higher than the 
desire to restate the obvious.  I think it would be a waste of time to 
produce errata that merely take implicitly application-dependent text and 
indicate explicitly that they are application-dependent.  Especially when 
the text can be interpreted no other way than being application-dependent.

In any case, this doesn't really help Florian, since he knows it is 
application-dependent, as do all of the implementors on the TC. 

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

Suggested ways to accomplish what exactly?  If ODF 1.2 tells how to do do 
numbering, then ODF 1.2 implementations know what to do.  If existing ODF 
1.1 implementations wish to be forwards compatible with ODF 1.2, then they 
can also implement what is specified in ODF 1.2.  There does not seem to 
be any shortage of information here. 

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

I'm not sure this solve Florian's issue either.  I don't think he is 
looking for a way to document what he does with numbering.  It sounds more 
like he is wondering what do to with other vendor's 1.1 documents.  But we 
can't force them to document what they did.  In theory we could 
speculatively put up such a wiki page and invite them to enter 
information.  But I doubt any vendor has not provided this information yet 
because they couldn't figure out how and where to post it. So I'm not sure 
this solves the real problem either.

Remember, we could also have bugs in ODF editors that cause them to write 
out documents which are not conformant.  Bugs are application-dependent as 
well. But I don't think the TC should be in the business of tracking 
specific bugs and application-dependent settings and telling other 
implementations what to do with them. That might be a good thing for 
vendors to do on their own or via other organizations, like the ODF 
Alliance.  But this would be entirely out of the scope of the TC's 

Best solution might be for Florian to talk to the specific vendor that he 
has problems with and try to get more information. 

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

Still assumes that vendors actually see value in writing up this 
information for Florian.

> 3. IS THAT IT?

I hope so.


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