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

On Mon, Oct 5, 2009 at 11:27 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Jonas Sicking wrote:
>>
>> ...
>> 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.
>> ...
>
> Again, this is simply incorrect. There are many ways to treat the tuple as a
> single argument, for instance using the Clark notation
> ("{namespaceUri}localName"), or using an object that contains both (such as
> QName in JAXP). That DOM doesn't provide that kind of API is a defect of the
> DOM, not a problem of namespaces per se -- how about fixing it?

First of all, the proposal discussed does not have any recommended
changes to the DOM in order to deal better with namespaced nodes. Once
such a proposal exists we can discuss it.

However I'll add that the namespace support added to DOM Level 2 has a
lot of pain, both for implementors and users. For many of the reasons
that I listed in my original email. Adding yet a third way to describe
node names seems like it would add even further confusion. However,
this discussion is theoretical until an actual proposal for
modifications to the DOM exists, so far I haven't seen one.

>> ...
>> As mentioned before, momentum seems to be moving away from XML
>> Namespaces rather than towards them (examples fixed based on received
>> comments):
>> ...
>
> I do not believe the momentum has changed over the last years. People
> occasionally complain, plan for something simpler, and then nothing happens
> because it would be a pain to introduce.

We already have one simpler thing, which is what HTML uses, where a
nodes meaning is derived from its nodeName alone.

>> ...
>>
>> 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
>> ...
>
> Again; that was somebody not being aware of DOM L2/L3 functions; you are
> implying that Shane doesn't understand the relevance of namespaceURI +
> localName, which is clearly incorrect.
>
> Please find better examples.

I do admit that after asking several times if prefix mappings were
declared based on attributes localName+namespaceURI, or if it was
based on nodeName alone, and each time getting the answer that it
"didn't matter" that I eventually gave up and stopped reading the
thread. So it's quite possible that understanding was developed later.

However, I think it's a strong indication that if we, who work with
these specs on almost a daily basis, have trouble understanding, then
the system is too complicated.

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

http://groups.google.com/group/mozilla.dev.tech.dom/msg/8b7c005a3932600a

>> 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.
>
> Again -- please do not complain about your emails getting ignored when you
> do ignore the feedback you're getting.
>
> It was already pointed out that RDF never used namespaces, so it, by
> definition, can't "move away" from them.

Ok, bad choice of words, RDF didn't move away from namespaces, it
chose not to use them.

>> 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.
>
> This might be a self-fulfilling prophecy; it's not surprising because the
> people involved in writing this spec did not like namespaces in the first
> place.

It's not a matter of like. Name+namespace tuples simply didn't solve
any real problems, and just added of complexity. For example every
type of event ended up having two initialization functions instead of
one. I personally argued for keeping namespaces in DOM Events many
years ago, and I think I can take a lot of blame for them surviving in
the DOM Level 3 Events drafts for so long. However eventually it
became clear to me too that even though they were easy to implement in
theory, in reality the cost was non-trivial, and the benefit non
existent.

/ Jonas

Received on Tuesday, 6 October 2009 08:12:52 UTC