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

On Feb 23, 2010, at 10:34 PM, Shelley Powers wrote:

> Maciej Stachowiak wrote:
>>
>> On Feb 23, 2010, at 6:07 PM, Ian Hickson wrote:
>>
>>>
>>> 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
>>
>> We also have a proposal to add the profile attribute as an  
>> extensibility mechanism, via a separate extension draft.
>>
>>
>> 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.
>
> Clarification: Another change proposal that should be in scope but  
> that is not an addition or a removal in this list, is a change  
> proposal to extend namespace support to HTML. Correct?

I would consider that an addition. But sure, proposals that change the  
range of applicability of these mechanisms would also be in scope. So  
if someone really wanted to propose allowing the rel attribute on  
<img> elements, that would be in scope (though in my opinion, it would  
be a silly idea).

>>
>> In particular, even though the issue text mentions XML-style  
>> namespaces, proposals for this issue would be in scope even if they  
>> do not direct relation or resemblance to Namespaces in XML.
>>
> Interesting. Rather opens the door for a new bug and separate change  
> proposal for adding namespaces to html completely apart from it  
> being a solution for this particular issue. As such, if this is  
> brought up at a later time, but in the context of extending support  
> for namespaces, directly, we wouldn't have to worry about re-opening  
> this issue, correct?

While it's not not required for proposals to resemble to Namespaces in  
XML to be in scope, it is certainly permitted.

I think the chairs would consider proposing a specific solution to the  
issue after it is resolved to be equivalent to reopening this issue.  
Thus, we would generally only allow it based on new information that  
was not available at the time of the original decision.

>> Since this is a very open-ended issue, and since many proposals  
>> made in the past have fairly complex implications, we will expect  
>> Change Proposals to spell out in detail any changes to document  
>> conformance or implementation processing requirements. As always,  
>> we will also expect proper rationale.
>
> Isn't the procedure for the chairs to make a Call for Proposals, and  
> give folks a month to respond, and then give them a month to write  
> the proposal?

Indeed, and that is what we're doing. Anyone who volunteers during  
that one-month period will get at least a month from the time they  
volunteer, and the chairs are likely to grant requests for reasonable  
extensions beyond that. My apologies if that wasn't clear.

> I'm just curious why we're not providing the breathing room for  
> would be the most extensive change proposal that would most likely  
> arise from this process.

If anyone thinks their proposal is complex enough to require extra  
time, they can ask the chairs for an extended deadline on the writing.

Regards,
Maciej