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