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

On Oct 5, 2009, at 12:03 AM, Sam Ruby wrote:

> Henri Sivonen wrote:
>> On Oct 3, 2009, at 16:27, Sam Ruby wrote:
>>> At the present time, I don't care what the issue is called, but I  
>>> don't see consensus on what the values of localName, prefix,  
>>> namespaceURI (and possibly tagUrn) should return, and that's what  
>>> I would like to see resolved.
>> 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.

Now, we could study parser behavior alternatives by looking at  
specific markup examples, and studying what various APIs would return.  
But it only makes sense to do that in the context of algorithm  
proposals. Trying to say what different APIs "should" return, one  
markup example at a time, is unlikely

So, focusing on the underlying parsing issue, we have at least two  
proposals on the table:
- HTML5's current parsing behavior for elements and attributes with  
colons in the name.
- Microsoft's proposed changes (not fully fleshed out in terms of  
parsing algorithm details, but we can probably see the implications).


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.
- I cannot live with Microsoft's current proposal - there is too much  
compatibility risk. I believe Philip has provided ample evidence.

(I'm probably not the only one who holds these views, but I'm at least  
one person willing to say so on the record.)

So far from the replies of others I see:
- No one has stated they can't live with HTML5's current parsing for  
elements and attributes with colons in the name (or provided rationale  
for feeling that way).
- No one has shown evidence for why the compatibility risk of  
Microsoft's proposal is low (other than the invalid argument in the  
proposal itself).
- No one has made any new proposals that address the compatibility  
concerns but still provide some kind of benefit.

Thus, at this point, I'm not seeing a real dispute. For there to be a  
real dispute, I think one of the types of replies I mentioned above  
would have to happen. Is anyone willing to do that? If not, I will  
tend to assume that we do in fact have consensus.

Regards,
Maciej


* It's true that browsers differ in the details of what gets  
capitalized and what doesn't for some of these APIs, and whether HTML  
elements in an HTML document end up in the null namespace or the XHTML  
namespace. But I don't think anyone has objected to these choices or  
suggested an alternative. The capitalization rules would be an API  
issue, the namespace URI for HTML elements is a parser issue. Focusing  
on these as if they are in any way related to Microsoft's proposal is  
a red herring.

Received on Monday, 5 October 2009 11:26:11 UTC