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] Thoughts on ODF-Next


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 12/17/2010 
02:22:31 PM:
> 
> RE: [office] Thoughts on ODF-Next
> 
> Michael, thank you for your thoughts on the future process for further
> development of the feature set of the OASIS ODF Standard.  I have one
> objection.
> 
> First, have a happy holiday season with the joyful satisfaction of 
knowing
> that the CD06 Public Review has actually commenced.
> 
> In short: I object to any introduction of speculative features by 
premature
> appropriation of the ODF x.y schemas and namespaces without any version
> control and without the full application of the standards-development
> process. 
> 


This problem is as old as the sea.  Vendors always have been implementing 
stuff before it has reached final standards approval. Heck, some vendors 
implement the features first, ship their products, and then propose the 
specifications for standardization. In some cases there has been 
criticism.  For example, the early implementations of 801.11N "Draft" in 
routers was criticized by some as signally an unwillingness on the part of 
those vendors to accommodate any changes to the spec.  I can certainly see 
that argument, but I'm not sure there is anything that a technical 
committee can do about this.  A vendor who is free to implement technology 
absent a standard is also free to implement that technology with a 
standard present, or even present only in draft.  The standards process 
only gives implementors rights.  It doesn't take any away.

We can certainly point to some regulated technologies where products 
require certification and can only be legally shipped if they conform to 
the published standard.  Telephony equipment was a prime example, in the 
regulated days, in order to protect the shared physical lines from damage 
and to prevent interference of signals.  I suppose you could make an 
analogy with exchanged electronic documents, where the network is more 
virtual than physical, but the detrimental effects of incompatibility are 
still very real.  But I don't see any regulator stepping in on that.

So, Dennis, I hear your concern and generally share it.  But all we can do 
on the TC is approve the specification.  We have no control over whether 
and when vendors implement it, or whether they do it well or poorly. Trust 
me, I wish I had that control ;-)

-Rob


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]