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

On Feb 23, 2010, at 9:52 PM, Ian Hickson wrote:

> On Tue, 23 Feb 2010, Maciej Stachowiak wrote:
>>
>> 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".

Indeed, and I personally think that proceeding from use cases is a  
good approach to this area.

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

In theory, you could write a proposal that presents the use cases for  
existing extensibility features and explains how they satisfy them.  
But I concede that you can't possibly counter proposals for this issue  
without seeing them first. Indeed, without seeing the concrete  
proposals and their rationale, it's hard to even determine if anyone  
will agree or disagree. But that's exactly why we are calling for  
proposals. We want to move this issue from a vague expression of  
concern to one or more concrete proposals that the Working Group can  
review.

And to be clear: there will be a fair opportunity to review, discuss,  
and if appropriate counter any proposals we do receive.

I think the precedential value here is limited - given our current  
decision policy, we are very unlikely to see any other issues raised  
that are so broad in scope. Given that this issue already exists,  
though, the chairs do not see any way to resolve it other than to  
proceed with the process.

Regards,
Maciej

Received on Wednesday, 24 February 2010 06:20:52 UTC