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] Do we really have that many options in ODF?

Hi Rob,

thank you for your thoughts. I agree to all of them.

Best regards


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
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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]