Re: TWO Change proposals for ISSUE-41 : Distributed Extensibility

On Tue, Mar 16, 2010 at 6:09 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Mar 15, 2010, at 9:48 PM, Ian Hickson wrote:
>
>  On Tue, 16 Mar 2010, Ennals, Robert wrote:
>>
>>>
>>> Proposal Y: tries to give a better fallback and backwards-compat story:
>>> http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple
>>>
>>
>> While I think this proposal is close to something that we should probably
>> add to HTML5, I don't think it's "Distributed Extensibility". It would be
>> more accurate to describe it as a convention for preventing vendor-
>> specific non-standard extensions from clashing with themselves and future
>> standard development.
>>
>
> It seems to me that this proposal adds a new extensibility mechanism, and
> thus is in the scope of the issue as I presented it last month:
>
> http://lists.w3.org/Archives/Public/public-html/2010Feb/0796.html
>
> The fact that you could also describe it in more specific terms, based on
> the nature and purpose of the proposed extensibility mechanism, does not
> make it out of scope for the issue.
>
> You are correct that ISSUE-41 is extremely broad. This issue predates not
> only the current process, but also any of the current set of Chairs. Under
> the new Decision Policy, it's unlikely we would ever again end up with such
> a broad scope for a single tracker issue. That being said, I don't think it
> would be legitimate to summarily close the issue without considering
> proposals.
>

There are some concerns that reflect fundamental disagreement with the
existing HTML5 specification, and the existing editor's personal viewpoints.
And not all of these concerns can be neatly packaged into a "bug".

Extensibility has been in the past, and continues to be a concern. How was
it supposed to be addressed? Go through the entire HTML5 specification, and
attach a bug for every area that could possibly be impacted? I would think
we'd rather have one issue, for the one major concern.

My Issue 94 related to the webcoresplit could also have widespread and
significant impact on the specification--far more than can be addressed in a
simple "bug". But this is the mechanism we're given, and we do what we can.

I don't agree with Robert's change proposal, but I respect that he made it
(them), and I hope the group gives them both due consideration.


>
> Regards,
> Maciej
>
>
>
Shelley