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

Possible Compromise solution for namespaces in HTML5

From: Ennals, Robert <robert.ennals@intel.com>
Date: Fri, 20 Nov 2009 22:33:26 +0000
To: "public-html@w3.org" <public-html@w3.org>
CC: "Carr, Wayne" <wayne.carr@intel.com>, "Tran, Dzung D" <dzung.d.tran@intel.com>
Message-ID: <EB332302649177439359CE520D92A0AF9F5F6ECD@irsmsx503.ger.corp.intel.com>
Hi Guys,

I'd like to propose a new compromise solution for allowing distributed extensibility and XML namespaces in HTML5. This proposal is based on conversations that I had with a lot of people at TPAC, and conversations that I had with other people subsequently. It shamelessly steals ideas from Liam's proposal and some of Tony Ross' ideas, but it's also a bit different. 

I should note that this is a proposal from me, not an official Intel corporate position.


The basic idea is this:
* An HTML5 document can contain tags and attributes that have prefixed names like "svg:bla".

* A particular prefix always means the same thing, in any file. Thus e.g. "svg" always means SVG

* A central registry records the meaning of all such prefixes, to prevent name clashes. The registry says what the namespace URL is, who registered it, what it does, and provides a link to a specification that would allow others to implement it. To appear in this registry, you are expected to publish a specification (not necessarily with the W3C), not be vendor specific, and be broadly useful

* You can also use a prefix beginning with "x-" (e.g. x-fbml) to denote an unregistered, experimental, or proprietary extension.

* A document can use a namespace declaration (e.g. xmlns:svg = "wibble") to bind a prefix to a namespace, but this MUST be the same namespace recorded in the registry for that prefix (except for an "x-" prefix). 

* A document is invalid if it contains multiple namespace declarations that bind the same prefix to different namespaces. 

* HTML5-specific tools will typically only look at the prefix, and ignore the namespace of the tag - since the xmlns declaration may be missing, and the correct namespace for the prefix is fixed. However the xmlns declaration must be present in order for the file to be a valid XML document.

* There are three levels of HTML5 validation:
	- Valid Pure HTML5 - the document contains no prefixed tags other than svg and mathml. It is guaranteed to render correctly in all HTML5 browsers.
	- Valid Extended HTML5 with features X and Y - the document contains registered prefixes X and Y, used correctly, in accordance with their specs. The validator should ideally also tell you what each of these features means, and which tools support them (reading from the registry)
	-  Valid HTML5 with proprietary extensions X and Y - warning that these are proprietary extensions that may not be widely supported


This proposal has the following features:
* It is compatible with existing XML namespaces
* It allows polyglot files that are both valid XML and valid HTML, and which use extensions
* It avoids confusions of namespace indirection, since a prefix always means the same thing. In particular, you can copy and paste code between arbitrary HTML files and it will always work.
* It makes it explicit when a tag comes from an extended namespace, by requiring that it have a prefix - thus making it easy for an author to know that they are relying on extended features
* It makes it explicit when a tag is using a proprietary extension that may not be well specified or supported
* The validator makes it clear to a content author whether their file uses extensions that may not be supported in other browsers 
* It encourages the authors of extensions to publish a spec and let others know what they are doing
* It doesn't require the parser to fetch an external file before it can parse a document
* It allows independent parties to develop useful extensions without the W3C having to act as a choke point to approve stuff


Apologies if someone has proposed this before.

Thoughts?


-Rob
Received on Friday, 20 November 2009 22:34:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:10 UTC