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

"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 
> > 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 

> 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 

I suspect a standards organization that wanted to enforce something like 
this could do so via their control of the trademarks associated with the 
standard, e.g., they could have a policy that says you can only use the 
trademark for implementations that conform to published/approved versions 
of the standard, etc.  But I'm not familiar with any organizations that 
have that rule.  It is more common among proprietary specifications, e.g., 
if you want to say "Compatible with Windows 7" on your box, then you must 
follow the logo guidelines defined by Microsoft. 



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