RE: [office] Public Comment #210 On Numbering

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

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 <meta:generator> "user agent" strings to help that out, it seems
to me.

 - Dennis


-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office/200903/msg00088.html
Sent: Monday, March 16, 2009 12:35
To: office@lists.oasis-open.org
Subject: Re: [office] Public Comment #210 On Numbering

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 03/16/2009 
12:24:40 PM:
http://lists.oasis-open.org/archives/office/200903/msg00087.html
[ ... ]

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

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

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.

-Rob

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php