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

On Oct 5, 2009, at 5:24 AM, Henri Sivonen wrote:

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

I agree with that too. What parsing/API behavior "should" be is a  
question of "ought", not "is", and therefore needs to come with an  
answer to "why". I don't see how anyone can give a rationale for a  
particular behavior without a high-level goal in mind. Without  
rationale, I don't see how people can persuade each other to change  
their positions.

However, since Sam is keen on discussing the concrete technical  
points, I wanted to make sure we frame that discussion properly.

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

I largely agree with that as well. To seriously consider a change to  
the parser, I'd need to understand how it improves things, and I'd  
need to be satisfied that it has suitable compatibility properties. I  
am prepared to reject Microsoft's proposal on compatibility grounds  
alone. For a proposal with suitable compatibility properties, it would  
be necessary to understand the rationale. Microsoft did in fact  
provide a rationale including use cases, and investigating those use  
cases in light of existing extensibility mechanisms is worthwhile.

>
> 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:40:47 UTC