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

On Oct 5, 2009, at 14:25, Maciej Stachowiak wrote:

> On Oct 5, 2009, at 12:03 AM, Sam Ruby wrote:
>
>> Henri Sivonen wrote:
>>> I think you are jumping ahead of things. We don't yet have  
>>> consensus on what problems to solve. We don't have consensus on  
>>> whether "decentralized extensibility" is the right way to solve  
>>> those problems. And we don't have consensus on whether Microsoft's  
>>> proposal (even on the high level) is the right kind of  
>>> "decentralized extensibility" for solving the problems.
>>> I think it would make the situation clearer if you could state  
>>> what problems you want solved, why you believe the HTML WG should  
>>> solve those problems, what "decentralized extensibility" is (so  
>>> the WG can recognize whether alternative proposals constitute  
>>> "decentralized extensibility"), why you believe "decentralized  
>>> extensibility" is the right way to solve the problems and why you  
>>> believe Microsoft's proposal is the right kind of "decentralized  
>>> extensibility".
>>
>> Consensus on what the values of localName, prefix, namespaceURI  
>> (and possibly tagUrn) should return -- that's what I would like to  
>> see resolved.
>
> If you really want to nail this down to concrete technical  
> questions, then it's really a question of parsing, not API behavior.  
> All of HTML5's current behavior flows directly from the element's or  
> attribute's {namespace, prefix, localName} tuple. That tuple is  
> either set by the parser, or as a result of creating elements or  
> attributes directly with DOM calls.(*)
>
> As I understand it, Microsoft's proposal does not change any  
> behavior for elements or attributes created with DOM APIs. All it  
> does is change the initial {namespace, prefix, localName} tuple for  
> elements and attributes created by the parser, and this is  
> observable through the API behavior. I don't believe Microsoft's  
> proposal can be explained solely in terms of API changes, without  
> having the parser do something different (at the very least record  
> some additional information). But it can be explained solely in  
> terms of parser changes.

I agree with this assessment. However, I further think it doesn't make  
sense to nail down technical questions without knowing the purpose of  
the nailing. Without knowing the purpose, one can't perform informed  
nailing. I'm interested in a *good* outcome--not just *any* outcome  
that enjoys consensus potentially because people participating in the  
consensus lacked information.

> Stating my personal views once again:
> - I can live with what HTML5's current parsing algorithm does to  
> elements and attributes with colons in the name.

In my view, the current parser spec addresses the problems it sets out  
to address in a satisfactory way (except likely for the way HTML  
<script> elements are closed).

I think the set of changes flowing from an empty set of additional  
problems to solve should be the empty set of changes. That is, I think  
it wouldn't be rational for me personally to be part of a consensus  
endorsing changes compared to the current spec without problems to  
solve to motivate the set of changes.

Sam, did you mean for the WG to endorse the current parsing spec text  
by consensus?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 5 October 2009 12:24:37 UTC