Re: [office] Thoughts on ODF-Next

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

On Fri, 2011-01-14 at 08:50 -0700, robert_weir@us.ibm.com wrote:
> "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 01/13/2011 
> 07:41:41 PM:
> > 
> > Re: [office] Thoughts on ODF-Next
> > 
> > On Thu, 2011-01-13 at 10:52 -0700, robert_weir@us.ibm.com wrote:
> > > I wonder if the impact of the problem would be reduced if we can turn 
> > > around standards faster?  In other words, would it be more tolerable 
> if a 
> > > vendor implements a draft 6 months before the standard is finally 
> approved 
> > > compared to implementing it 2 years before approval?  I think that is 
> > > something we have more direct control over.
> > > 
> > 
> > The problem I have is when a vendor implements a certain feature from a
> > draft and the specification is found wanting. Obviously there would be
> > some reluctance to change a specification in a incompatible way to that
> > implementation. So implementing a feature from a draft can have the
> > effect of cutting off any improvements to that feature.
> > 
> 
> This issue has been noted in the larger tech industry.  For example, the 
> 801.11 N wifi standard took 7 years to develop.  But hardware supporting 
> "draft" versions were in the market several years before the standard was 
> finalized.  This creates in incumbency effect that benefited large chip 
> makers, who were able to simultaneously move on the market faster, but 
> also ensure that the standard did not change contrary to their investment. 
>  So the effect is real.  And we can certainly point to other vendors whose 
> practice is to release a product first, and then submit the technology for 
> standardization, but with committee charters that forbid incompatible 
> changes.
> 
> > Now if the feature were implemented using foreign elements no such
> > problem would exist and if the spec does not change it would be trivial
> > to change the element name/namespace to match the approved standard.
> 
> That is one approach, but not one that we (the ODF TC) have any ability to 
> mandate. 
> 

While I realize that we can't mandate that and in fact have no control
over whether a vendor calls their format ODF1.3 or whatever, I thin kwe
at least should not encourage that behaviour as suggested.

Andreas