[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Do we really have that many options in ODF?
"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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]