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

On Mon, Oct 5, 2009 at 4:25 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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 feel the same way, though for slightly different reasons. While I am
concerned about compatibility risks, i'm more concerned about platform
complexity for authors. I've stated this before, but since it appeared
that some people missed it so I'll try to redo it again in a more
official manner:

I believe XML Namspaces (as well as the XML Namespaces-like proposal
from microsoft) is too complex because:

1. The use of prefixes means that copy-n-paste on a source level
becomes fragile.
2. People appear to think of nodes as getting their functionality
through their nodeName, rather than through their
localName+namespaceURI. I.e. I've found that people get very confused
if the 'svg' prefix is bound to any other namespace than the one used
by the SVG specifications.
3. The fact that the effective name is a tuple consisting of
localName+namespaceURI, rather than a simple string is generally a
pain. Implementations have to lug around at least two arguments
instead of one though function calls, stored members, hash keys etc.
Many times 3. Users of APIs have to specify two parameters in function
calls, and remember their order, store two strings instead of one
whenever they want to store element name, etc.

As mentioned before, momentum seems to be moving away from XML
Namespaces rather than towards them (examples fixed based on received
comments):

The most recent example of 2 above was the discussion on RDFa+HTML
where it was clear that even the experts that developed RDFa thought
of nodes as receiving their meaning from their nodeName rather than
from their localName+namespaceURI. One example is
http://lists.w3.org/Archives/Public/public-html/2009Sep/0923.html

Additionally, the SVG working group is hard at work trying to get away
from exposing their users (SVG authors) to the SVG namespace. I'm
assuming that this is based on feedback from authors disliking the SVG
namespace.

The RDF and RDFa specs has moved away from the namespacing mechanism
that XML Namespaces is using. RDFa is based on CURIEs, which is a
compacted single string, rather than the string-tuple that XML
Namespaces force upon users.

Similarly the DOM Level 3 Events spec recently decided to drop the use
of name+namespace tuple inspired by XML Namespaces, and instead chose
to use a single string to identify Events.

So all in all it feels like momentum is moving away from the XML
Namespaces model, rather than towards it.

/ Jonas

Received on Tuesday, 6 October 2009 03:48:38 UTC