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

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.

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

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.

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

Such an API need not be defined in HTML5.

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

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

>> Given that this clearly is a contentious topic, my suggestion is that 
>> this initially be pursued as a separate draft.
>>
>> On a technical level, what would be value of the namespaceURI for the 
>> element with a localName of 'foo:bar' in the following non-conforming 
>> document?
> 
> Defining the exact parsing algorithm changes for Microsoft's proposal 
> would answer this and many similar questions.

+1

>  - Maciej

- Sam Ruby

[1] 
http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility

Received on Saturday, 3 October 2009 00:38:44 UTC