Re: ISSUE-41/ACTION-97 decentralized-extensibility

On Oct 2, 2009, at 5:33 PM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Oct 1, 2009, at 7:14 AM, Sam Ruby wrote:
>>> Adrian Bateman wrote:
>>>> Tony has written up our thoughts on Distributed (or Decentralized)
>>>> Extensibility in the attached HTML document. Tony is on vacation  
>>>> so I
>>>> am posting on his behalf.
>>>> We have included a base proposal with several optional components.
>>>> The purpose of this document is to seed a discussion and we expect
>>>> the discussion to drive improvements in the document.
>>>
>>> "Namespaces in XML 1.0"[1] is a separate document than "Extensible  
>>> Markup Language 1.0"[2]
>>>
>>> Is there a technical reason why "Namespaces in HTML5" couldn't be  
>>> a separate document from "HTML5"[3]; and in fact potentially be  
>>> one of the "other applicable specifications"[4] alluded to by that  
>>> document?  If so, what changes to the proposal and/or HTML5 would  
>>> enable such to be pursued?
>> Intriguing idea. Some thoughts:
>> 1) Microsoft's proposal as currently stated could not use the  
>> "other applicable specifications" extension point. That extension  
>> point allows a separate extension to add to the set of conforming  
>> elements and attributes, and to define the processing requirements  
>> for a DOM containing those constructs. But it does not provide a  
>> way to change the parsing algorithm. Microsoft's proposal would  
>> require changes to the parsing algorithm (both parser and  
>> tokenizer, I believe).
>> 2) A proposal that only extended the set of conforming elements and  
>> attributes, without changing the parsing requirements, could use  
>> the "other applicable specifications" extension point. Examples of  
>> proposals along these lines:
>>    (a) Use elements and attributes with : in the name, but the DOM  
>> is built as per HTML parsing today, so everything is in the null  
>> namespace.
>
> For elements, I think you mean xhtml's namespace?  In any case, this  
> is a nit, and doesn't affect the overall point you are trying to make.

Indeed, my mistake.

>
>>    (b) Use the -vendor-prefix pattern used by CSS, instead of colon  
>> syntax, as suggested by Bert Bos.
>> 3) A spec based on Microsoft's proposal could state changes to the  
>> parsing algorithm, or just define a complete modified copy of the  
>> parsing algorithm. After all, Namespaces in XML modifies XML  
>> parsing by modifying the grammar of XML, even though that was never  
>> an official extension point. I think changes to the HTML5 parsing  
>> algorithm are necessary in some form to fully define Microsoft's  
>> proposal.
>
> I would not be in favor of this, but am wondering if there are small  
> changes to the HTML5 spec that might enable #2 to be pursued?  I  
> won't speculate on what those changes might be.

#2 can be pursued with no changes to the HTML5 spec.

>
> Orthogonal to this, and treat this entirely as brainstorming at this  
> point.  Permit me to postulate that something along the lines of MS  
> use cases are valid... I'm not asking that that be determined at  
> this time, just for purpose of discussion assume that.  Given that  
> (quite possibly shaky assumption), and furthermore assume that for  
> compatibility reasons the current DOM based NS APIs must return back  
> something closely approximating what they currently return, perhaps  
> a small set of APIs (perhaps even only one API) is needed which  
> return back a different value.

That would be closer to what IE actually does.

> If that is not clear, consider a getEffectiveNamespaceURI (don't get  
> hung up on the name, I suck at naming).  Such an API need not return  
> the same value as getNamespaceURI.  Such an API could be defined in  
> a separate spec.

IE calls it "tagUrn".

> Perhaps it could be implemented exclusively in ES (and I posit that  
> it probably has been done a number of times already).  Some  
> implementations may chose to implement it natively, but would be  
> under no obligation to do so.

A method with behavior matching IE's tagUrn could not be implemented  
in pure ES on top of the DOM, due to the difference between binding  
prefixes at parse time and binding at lookup time. A method with  
deliberately different semantics could be implemented in pure ES on  
top of the DOM.

> Such an API need not be defined in HTML5.

That is true.

Is it ok that in an XML document, the API would give different answers  
than the built-in XML namespace mechanism? Would it be acceptable to  
encourage consumers to process XML content based on "effective  
namespace URI" instead of based on actual Namespaces in XML processing?

I suggest that if we introduce a mechanism with different behavior  
than either Namespaces in XML or IE's HTML namespaces, but usable in  
the same document at the same time, then it should probably use a  
different syntax than Namespaces in XML.

>
>> 4) I'm not sure a spec along the lines of point (3) would ever be  
>> adopted by more than one browser. In fact, I'm not sure it would  
>> ever be adopted by more than zero. It seems like a bad idea pursue  
>> a standard that would not be implemented, or that would be  
>> implemented only by a single vendor. That's not necessarily a  
>> blocker to publishing a Working Draft, but I think it would be  
>> unwise to take a spec to Last Call if there is no feasible path for  
>> it to exit CR. Specific concerns:
>>    (a) Microsoft's proposal differs greatly from behavior in any  
>> existing browser, including IE, thus the compatibility risk is  
>> likely quite high. This might even make Microsoft abandon the  
>> proposal if they actually implemented it. (Studies of compatibility  
>> impact, or changes to the proposal, could change this.)
>
> It is also possible (though I will grant, unlikely) that the current  
> state is broken, and that given MS's input the browsers vendors  
> will, collectively, want to converge onto a different point than the  
> group which did not include MS did.

That is possible, but not responsive to my point. A proposal to  
implement exactly IE's namespaces-in-HTML support would have  
considerably less compatibility risk and might lead to the kind of  
fruitful discussion you propose. But Microsoft's proposal has many  
details where it differs from *both* IE *and* other browsers in the  
same way.

>>    (b) Representatives of browser implementors other than Microsoft  
>> have expressed reluctance to support a mechanism similar to XML  
>> namespaces in text/html syntax for philosophical and technical  
>> reasons. In particular, there are concerns about the usability of  
>> prefix-based indirection for authors, and about the wisdom of  
>> allowing unilateral extensions to the language in such a way that  
>> content using them is still conforming. (It may be these concerns  
>> can be addressed by changes to the proposal.)
>
> I recognize that debate pattern.  I can reply in kind.  :-)
>
> I can also name representatives of browser implementors other than  
> Microsoft which have expressed support for a mechanism similar to  
> XML namespaces in text/html.
>
> For now, I will simply name one: Brendan Eich.
>
> http://weblogs.mozillazine.org/roadmap/archives/2007/03/the_open_web_and_its_adversari.html
>
> "Consider just the open standards that make up the major web content  
> languages: HTML, CSS, DOM, JS ... the Web is alive precisely because  
> of the distributed extensibility of its content languages".  Shortly  
> after I wrote it, I specifically discussed with Brendan my previous  
> proposal[1] which shares a number of similarities with MS's current  
> proposal, and he indicated (to be fair: at the time) that he was in  
> support of the general approach, though clearly there were a lot of  
> details to work out.
>
> I've added him to the copy list to see if he wishes to comment  
> further.

If Mozilla expresses interest in implementing some form of namespaces  
in HTML, then that would certainly change the picture. For now, I put  
more weight on recent clear statements from Jonas and Henri, than an  
ambiguous remark in a 2.5-year-old blog post from Brendan (to be fair,  
none of the three of them claimed to be speaking officially for  
Mozilla). In context, it does not look to me like Brendan was using  
"distributed extensibility" as a code word for "XML-like namespaces".  
But Brendan can speak for himself.

Regards,
Maciej

Received on Saturday, 3 October 2009 01:08:22 UTC