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

On Oct 2, 2009, at 6:35 PM, Sam Ruby wrote:

> Maciej Stachowiak wrote:
>> On Oct 2, 2009, at 5:33 PM, Sam Ruby wrote:
>>>> 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.
>
> I guess I was unclear.  If #2 is not viable given the current HTML5,  
> the question I was attempting to pose is: what changes would be  
> required to HTML5 in order to enable #2 to be viable for the  
> remainder?

I think #2 *is* viable given the current HTML5. That was the point of  
#2 - what kind of proposals could use the HTML5 "other applicable  
specifications" hook with no changes to HTML5 itself. This would  
require a different basic design than Microsoft's proposal, which  
intrinsically requires parser changes. I suggested two such designs.

Quoting myself from before, with slight corrections:

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 elements are in the xhtml  
namespace and attributes are in the null namespace.
    (b) Use the -vendor-prefix pattern used by CSS, instead of colon  
syntax, as suggested by Bert Bos.

Now, maybe you are suggesting that HTML5 changes could allow  
Microsoft's exact proposal to be expressed in #2 style. I can think of  
one possibility - make all of the parser changes required for  
Microsoft's proposal, but without making any markup using those  
mechanisms conforming. But I think that would not provide any actual  
decoupling, and these changes would not be small. Perhaps there is a  
clean way to add an extension hook instead, but I cannot think of one  
offhand.


> I'm simply motivated to look for ways of decoupling these... both to  
> allow HTML5 to proceed unfettered, and to allow the proposal to  
> proceed.  As an analogy, if there was an insistence that RDFa be  
> defined in HTML5 *before* RDFa in HTML was fully defined (and to  
> date, it clearly still has a way to go), I don't think we could have  
> made the progress to date that we have done.

RDFa is a very successful example of decoupling, and I commend you for  
looking for a way to follow the same model. With RDFa this was easy,  
because there are no conformance requirements for browsers (unless  
they someday choose to extract RDFa information). Microsoft's proposal  
is different - would change conformance requirements for browsers,  
indeed it would require behavior contrary to the HTML5 parsing  
algorithm. That aspect of the proposal cannot readily be decoupled  
from the HTML5 spec.

Regards,
Maciej

Received on Saturday, 3 October 2009 01:58:46 UTC