RE: [office] Do we really have that many options in ODF?

[robert_weir@us.ibm.com]

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 05/07/2010 
12:55:06 PM:

> 
> I would say that everywhere there is a "SHOULD," "MAY,"
> "implementation-defined," and especially "implementation-dependent"
> (including when implicit in the omission of sufficient detail for it to 
be
> anything but implementation-dependent) that is PERMISSION TO CONFORMING
> PRODUCERS, we need to consider the unnatural acts and barriers that this
> imposes on consumers. 
> 

I don't think I'd say "unnatural" here.  The history of this area is quite 
clear.  There has never been an interoperable, widely-adopted, open 
standard format for office documents.  For the last 30-years it has been a 
constant state of every vendor defining their own format and than trying 
to get whatever degree of interoperability they can, via whatever means 
they could scrap together.  I think that is the  "natural" state of 
things. 

Standardization in this area is a recent innovation.  Clearly if we can 
agree on every last detail of the syntax and semantics of office 
documents, and get all vendors to implement it according to spec, then we 
have achieved a minor miracle.  We might not get there all in one step, 
but every step we take in that direction is progress.  This is not an 
all-or-nothing thing. 

I think I've said before that there are several ways we can fail:

1) Specifying things too loosely, that implementations are not able, with 
reasonable efforts, to achieve interoperability.  Note that I don't state 
this in absolute terms, like "Implementers from the planet Mars, who have 
never seen a word processor, must be able to implement 100% of ODF while 
locked in a room with only access to the standard and a copy of a the 
Shorter Oxford English Dictionary."  I expect that interoperability will 
not be achieved without extra-standards efforts, including testing, 
plugfests, etc.  That is engineering, not mathematics.

2) Specifying things too narrowly, that we arbitrarily exclude reasonable 
variation and preferences.  As we all know, it is possible to write a very 
detailed, much longer specification that describes in monumental detail 
the inner secrets of a single implementation, and then have very few (or 
no) conforming implementations.  I don't think we need to repeat that.

3) Specifying things that no one will implement.  Sure, it would be nice 
if by the stroke of a pen we could force trillion dollar multinational 
corporations to change their 15-year old established products to meet our 
whims, the fact is that is a delusional belief.  A standard might be able 
to get a little ahead of implementations, like we did with the RDF support 
in 1.2.  But that only works when you have implementers already committed 
to implement it. 

4) Specifying things too slowly, that the fruits of our efforts are not 
made available in a timely fashion and therefore cease to be relevant to 
the market. 

Obviously, #1 and #2 are trade-offs.  I think reasonable people can 
disagree on how these trade-offs are made.  With more time we might make 
improvements here.  But with an eye on #4, I wonder whether that more time 
is best done post ODF 1.2?  There are a lot of improvements in ODF 1.2 
that we risk holding back from standardization if we delay 1.2 further. 
Sure there is more work we could do.  But there is even more work that 
we've already done.  At some point I think we need to let go, and allow 
the spec flow through the rest of the process, while at the same time 
committing ourselves to continue that progress in the next revision. 
Perfect?  No.  Much improved?  Yes.

Regards,

-Rob