Re: ISSUE-41: decentralized-extensibility - Chairs Solicit Proposals

On Tue, 23 Feb 2010, Maciej Stachowiak wrote:
> On Feb 23, 2010, at 6:07 PM, Ian Hickson wrote:
> > On Tue, 23 Feb 2010, Maciej Stachowiak wrote:
> > > 
> > > "Decentralized Extensibility"
> > > 
> > > This issue has been open nearly two years, and there has been much 
> > > discussion. It was originally raised before the current decision 
> > > policy went into effect. While our drafts include a number of 
> > > extensibility mechanisms, there have been many suggestions for 
> > > additional extensibility mechanisms. Some WG members have expressed 
> > > their eagerness to write up their ideas more formally and move 
> > > forwad on this issue. Per the decision policy, at this time the 
> > > chairs would like to solicit volunteers to write Change Proposals.
> > 
> > This seems like a very vague issue. What exactly is the problem for 
> > this issue? (i.e. how do I know if something I want to propose is in 
> > scope of this issue or not?)
> 
> This issue is about extensibility mechanisms for HTML5. I am aware of 
> the following extensibility mechanisms, either in the HTML5 draft 
> proper, or defined in extension specs:
> 
> - class attribute
> - <a rel> / <link rel>
> - <meta name content>
> - data-* attributes
> - "Other applicable specifications" extension point
> - <script type=""> with a custom type to embed raw data
> - <embed>/<object>
> - XML Namespaces (only in the XML serialization)
> - Microdata
> - HTML+RDFa

Each of these has very specific problems that it is trying to address; 
they're mostly not interchangeable. They're all extensibility mechanisms 
just like many of the elements are for "semantics" or all the APIs are for 
"scripting" or a number of elements are for "embedding content".


> A Change Proposal would be in scope for this issue if it proposed one or more
> of the following:
> - Add one or more extension mechanisms to the above list, either in the main
> spec or as a separate extension draft.
> - Remove one or more of the above listed extension mechanisms.
> - Make no change to our set of extension mechanisms.

I think it sets a very bad precedent to call for change proposals on such 
a hugely open-ended topic without a clear problem description. For 
instance, I wouldn't even know how to begin to write a no-change proposal 
for such a wide topic. What possible rationale could one give for simply 
not wanting to change anything to do with extensibility?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 24 February 2010 05:53:25 UTC