- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Thu, 5 Nov 2009 16:10:32 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Liam Quin <liam@w3.org>, HTML WG <public-html@w3.org>
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. 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. 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. Browsers could just treat the content according to HTML5 rules if they don't know how to handle it, but tools designed to process the particular namespaces could look at the declarations. This puts the burden of dealing with conflicts in the right place: only on the authors and implementers who actually run into the conflicts. *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. Perhaps someone else could clarify. If I'm understanding correctly, I think this would be an excellent compromise on the namespace issue, since it incorporates the main benefits ascribed to namespaces (disambiguation and optional self-documentation) while removing all of their problems (no difference to authors and implementers of mainstream specs, compared to the current situation).
Received on Thursday, 5 November 2009 21:11:12 UTC