W3C home > Mailing lists > Public > public-html@w3.org > October 2009

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 06 Oct 2009 10:33:38 +0200
Message-ID: <4ACB00E2.6090908@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Henri Sivonen <hsivonen@iki.fi>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Brendan Eich <brendan@mozilla.org>
Jonas Sicking wrote:
> ...
> 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.
> ...

I agree that adding something else should be avoided. One way to avoid 
it would be to align namspaceURI/localName more between text/html and 
application/xhtml+xml.

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

Yes, but sometimes simple is too simple.

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

I found that reasoning confusing as well.

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

I do not believe that anybody involved in this discussion had problems 
understanding how namespaces work. It was just confusion about a 
specific API.

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

Oh, it's about JS programmers creating SVG elements programatically, not 
authors of SVG documents.

That proposal seems to be only partly related to namespaces, it suggests 
replacing many DOM calls by a single one as a convenience. It would be 
useful for HTML as well. (And, again, if people have trouble specifying 
the NS URI they really should declare a global string variable and use 
that).

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

That may be true; but in case it is, it may have been influenced by the 
fact that both RDF and XML Namespaces were developed in the same time frame.

Let me also note that RDF, as XML namespaces, uses URIs for disambiguation.

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

But that's an API choice. A single function would have been sufficient 
by using the right syntax. (Again, Clark notation)

> ...

BR, Julian
Received on Tuesday, 6 October 2009 08:34:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:50 GMT