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

Re: Automatic XML namespaces

From: Liam Quin <liam@w3.org>
Date: Fri, 6 Nov 2009 16:36:54 -0500
To: Aryeh Gregor <Simetrical+w3c@gmail.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, Liam Quin <liam@w3.org>, HTML WG <public-html@w3.org>
Message-ID: <20091106213654.GA18802@w3.org>
On Thu, Nov 05, 2009 at 04:10:32PM -0500, Aryeh Gregor wrote:
> On Thu, Nov 5, 2009 at 2:26 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
> > How would this differ from what HTML5 specifies now?
> My impression is that for browsers, it would not differ. They would
> use a hardcoded list of namespace mappings and treat unknown elements
> just as they do now.

Right, the purpose of "imaginary namespaces" is to give the XML
workd a way to enjoy predefined lists of namespaces, and to use
that to "bless" what HTML5 is doing.

> As far as I can tell, this proposal aims to let
> XML-processing tools treat namespaces much like HTML5 does, specifying
> the automatic namespace feature of HTML5 in a more broadly usable way.

>  This would hopefully preserve the theoretical disambiguation
> advantages of namespaces with the practical authoring advantages of
> unnamespaced content: in the common case of no conflicts between major
> specs, namespaces can be almost ignored by authors.

> In particular, I'm assuming that an ns.xml would be optional for all
> users of automatic namespaces -- i.e., that UAs could be permitted by
> applicable specifications to use out-of-band information (like MIME
> type) to decide which namespaces to use, and ignore explicit automatic
> NS declarations.

They could ignore a request to use the standardised "ns.xml" file
in all cases.  If the URI to the ns file isn't known, ideally,
a Web browser would fetch it.  A rule saying that it's not possible
to override the built-in defaults would mean that rendering could
begin and proceed at least until an unknown element or attribute
was encountered.

> If a document author wanted to use elements in a new
> namespace, but the names conflicted with elements they were already
> using in another namespace, they could provide an explicit ns.xml (or
> similar declaration; it could be in-band) to disambiguate.

Yes (or, in XML, they can continue to use the xmlns syntax)

> This puts the burden of
> dealing with conflicts in the right place: only on the authors and
> implementers who actually run into the conflicts.
I think we agree here.

> *Preemptive*
> resolution of conflicts for all authors and implementers of XML-based
> documents is an unreasonable burden, given that there need be no
> conflicts between widely-used, centrally-specified standards.
> I certainly don't feel I understand the perceived advantages of
> namespaces well enough to be sure of my interpretation, though.
In the XML world, the advantage is that you can do namespace
mashups, and also that you can safely do experimentation --
e.g. I can make a "chair" element in my own namespaces, and because
it's not <my:chair> but instead <chair>, if, later, HTML were
to include it, my documents would still work.

Thanks for commenting -- I'm sorry not to reply to all the
comments this week, next week I will try to send a more
detailed/more specific/clearer proposal.


Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/
Received on Friday, 6 November 2009 21:37:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:53 UTC