W3C home > Mailing lists > Public > public-html@w3.org > February 2010

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

From: Shelley Powers <shelleypowers@burningbird.net>
Date: Wed, 24 Feb 2010 00:34:02 -0600
Message-ID: <4B84C85A.4010002@burningbird.net>
To: Maciej Stachowiak <mjs@apple.com>
CC: Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
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
>
> 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?

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

> 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.
>
> Regards,
> Maciej
>
>

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

Shelley
Received on Wednesday, 24 February 2010 06:34:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:14 UTC