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

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

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

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

  - Maciej

>
> <!DOCTYPE html>
> <html>
> <head>
> <title>hoisted</title>
> </head>
> <body xmlns:foo="http://example.com/foo/1">
> <table xmlns:foo="http://example.com/foo/2">
>  <tbody  xmlns:foo="http://example.com/foo/3">
>    <foo:bar></foo:bar>
>    <tr><td>xxx</td></tr>
>  </tbody>
> </table>
> </body>
> </html>
>
> To assist with this here are two URI's for exploration:
>
> http://tinyurl.com/yauzj4e
> http://tinyurl.com/y88hhdw
>
> Special note: the placement of this element in IE8 and Opera differs  
> from the placement of this element in Mozilla, WebKit and HTML5.   
> Also note the localName of this element assigned by the HTML5 Live  
> DOM Viewer.
>
>> Regards,
>> Adrian.
>
> - Sam Ruby
>
> [1] http://www.w3.org/TR/REC-xml-names/
> [2] http://www.w3.org/TR/xml/
> [3] http://www.w3.org/TR/html5/
> [4] http://www.w3.org/TR/html5/dom.html#semantics-0
>
>

Received on Friday, 2 October 2009 23:52:23 UTC