[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?
Hi Rob, thank you for your thoughts. I agree to all of them. Best regards Michael On 05/07/10 19:46, robert_weir@us.ibm.com wrote: > "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 > > --------------------------------------------------------------------- > 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 > -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Jürgen Kunz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]