Re: Possible *third* proposal for ISSUE-41 Distributed Extensibility

On Fri, Mar 19, 2010 at 7:34 AM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 03/18/2010 11:12 PM, Tab Atkins Jr. wrote:
>
>> On Thu, Mar 18, 2010 at 3:17 PM, Ennals, Robert<robert.ennals@intel.com>
>>  wrote:
>>
>>> Comments?
>>>
>>> If it seems that people might like this then I’ll write it up formally.
>>>
>>
>> Not a fan.  *Anything* that uses an XML Namespaces-like mechanism for
>> embedding new elements is a bad idea, imo, because the fallback story
>> (necessary to activate an experimental feature in multiple browsers,
>> and to transition from experimental to standardized versions) is so
>> horrible.  Maciej argued that it may be worse than not doing it at
>> all, and just using the public name from the start.
>>
>> This is simply unusable as a way to allow browsers to add experimental
>> features without clashing with each other and future standardized
>> versions of the feature.
>>
>
> [co-chair hat off]
>
> I don't believe that this proposal should be used by browsers to add
> experimental features.
>
>
Agree. Not sure where this interpretation arose.



> Nor do I believe that this proposal should change parsing rules;
> furthermore XML Namespaces are published in a separate document from the XML
> specification, I see no reason why this proposal needs to be in the HTML5
> specification at all; but both are tangents, More here:
>
>  http://intertwingly.net/blog/2009/04/08/HTML-Reunification
>  http://lists.w3.org/Archives/Public/public-html/2009Oct/0180.html
>
> Net: I believe that Author Conformance Requirements are the real issue
> here, and until there is a coherent rationale for which conformance
> requirements are included and which are not, we will asymptotically approach
> a state where all implementation issues are resolved and what remains is a
> document conformance issues:
>
>  http://lists.w3.org/Archives/Public/public-html/2010Mar/0314.html
>
> I'm awaiting for rationale to be provided using the only mechanism
> available to request such:
>
>  http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034
>
> If there is a coherent rationale provided that I can then use as a basis
> for filing individual bug reports on, I'll do that.  If not, I'll escalate
> the issue and volunteer to write a change proposal which revisits this from
> the top down.
>

What is the timeline for a response to this bug?  I think an action item
asking for this to have a response within a reasonable time frame is
warranted.



>
> My recommendation (which nobody needs to follow) is that the third proposal
> not be pursued at this time, and that depending on the outcome of issue 41
> and bug 7034, a proposal may be made later to address authoring extensions,
> and that such a proposal is likely to take the form of a separate document.
>
>
Interesting. And a valid suggestion, particularly considering how
complicated and large the existing document is. It would also remove this
particularly difficult aspect from being a block to publication of HTML5,
and allow such an authoring extension to progress at its own rate.

I'm also hoping it prevents another slap-dash toss of stuff into the HTML5
tome that is supposedly providing a "solution" to a problem/use case, but
only adds yet more cruft. Not to point specifically at Robert's work -- just
the fact that we're talking major extensions being shoe horned into the same
bug/issue process that covers things such as a single attribute (table
summary).

(Though all things considered, we could potentially solve the issue of
distributed extensibility in HTML in less time than it seems to have taken
just to solve the issue of one small element attribute.)



>  ~TJ
>>
>
> - Sam Ruby
>
>
Shelley