Re: [office] what do mean by standard, and extensible?

["David A. Wheeler" <dwheeler@dwheeler.com>]

> An issue we've been dealing with in the metadata group, Rick Jelliffe  
> is dinging us a bit on some OpenFormula related wiki content:
> <http://www.oreillynet.com/xml/blog/2006/09/freaked_out_by_odfs_definition.html>
> 
> For metadata, I actually thing Rick is a bit off-base that there need  
> be such a gulf between the two -- one can standardize the model without  
> standardizing the specific markup; standardize some of the markup/terms  
> without worrying about standardizing all of it -- but I think it's  
> worth clarifying the issue he raises as we move forward.

Agreed.

The text he complains about first was to counter a DIFFERENT
misunderstanding. Which just goes to show that it's hard to write text
that can't be misunderstood by someone :-(.
I think I'll try to clarify the Wiki.  But this notion that implementations must
NEVER be allowed to implement a subset or superset is a bad one.
Users need to know if it's subsetted, or what the nonstandard extensions ARE,
but that is NOT the same thing.

> When do we standardize something, and when do we leave a structure in  
> place that allows extension to happen without the involvement of the TC?
>
> When, for example, should a formula extension be submitted for  
> inclusion in the spec, and when not? Is extension here just a mechanism  
> to fill the time gap between implementation and TC standardization?

I'd characterize it slightly differently.
In my mind, implementors create extensions as "experiments" to try to improve
the standard.  The experiments that don't work out quietly fade away.
The experiments that succeed get standardized.  And that's how standards
move forward to handle changing needs over time.

Sometimes extensions turn out to not work,
or only work in one situation that will never happen again.
It's dangerous to do a lot of "inventing" in a standards body;
it's generally more successful if you start with an existing implementation,
and then refine it.

Maybe the terminology of "rights" would help:
* Implementors need the right to extend the standard, or implement
   a subset, to handle different problems
* Customers need the right to KNOW if an implementation implements
   the whole spec or a subset, and KNOW what are the extensions so that
   they can avoid them (for interoperability's sake).

> For metadata, I think the standards of inclusion would likely be  
> different, but we'd still want some statement on this.

Any suggestions on how to word one?

--- David A. Wheeler