RE: Possible Compromise solution for namespaces in HTML5

For the purposes of playing nice with the issue tracker, I should mention that this is a proposed resolution for ISSUE-41 "Decentralized extensibility".

-Rob

> -----Original Message-----
> From: Ennals, Robert
> Sent: Friday, November 20, 2009 2:33 PM
> To: 'public-html@w3.org'
> Cc: Carr, Wayne; Tran, Dzung D
> Subject: Possible Compromise solution for namespaces in HTML5
> 
> 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 Tuesday, 24 November 2009 06:54:42 UTC