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 20:54:28 +0200
Message-ID: <4ACB9264.9070405@gmx.de>
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
CC: Jonas Sicking <jonas@sicking.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>
Aryeh Gregor wrote:
> On Tue, Oct 6, 2009 at 4:33 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> Jonas Sicking wrote:
>>> 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.
> 
> I don't normally pitch in on these namespace discussions, because they
> go in circles.  But I'm really not clear on something here.  What is
> the practical advantage of requiring a namespace declaration that
> causes "foo:bar" to be treated as "{http://something-or-other}bar",
> over just treating "foo:bar" (or for that matter "foo_bar" or
> whatever) as an opaque string, as with CSS vendor-specific extensions?
>  After reading numerous lengthy arguments over the matter, I can only
> think of about two reasons:
> 
> 1) It prevents inadvertent prefix collisions.

Yes.

> 2) It's widely used already.

Yes.

And it *allows* (*not* requires) following the URI to lookup information.

> The risk of prefix collisions (1) seems minimal.  Allowing extensions
> to use a global namespace and trusting implementers to not choose
> names that are likely to conflict tends to work fairly well.  CSS
> vendor extensions are one good example.  HTTP and e-mail X-* headers
> (one namespace for all extensions) also haven't caused major problems

There's a registry for header names.

> in practice.  Problems would only have to arise, anyway, if both the
> prefix *and* the tag name (or attribute, etc.) were the same in two
> different extensions, *and* someone wanted to use both extensions in
> the same document.  This benefit therefore seems minor at best.

Well, there's disagreement about that.

> (2) might be true in a generic sense, but not in the specific case of
> HTML, and particularly not in text/html.  To the contrary, supporting
> XML-style namespaces in text/html would apparently cause significant
> interoperability problems with existing content.  At best, widespread

It would be nice to know *how* significant. If it's all about MS Word's 
HTML output with bogus namespaces, it would be trivial to exclude those 
from processing. We need more information.

> use in other standards is a very weak argument from a practical point
> of view.
> 
> What exactly is too simple about relying only on nodeName?

The assumption is that a simple short string is not sufficient for 
disambiguation.

BR, Julian
Received on Tuesday, 6 October 2009 18:55:07 GMT

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