Re: Possible Compromise solution for namespaces in HTML5

On Fri, Nov 20, 2009 at 4:33 PM, Ennals, Robert <robert.ennals@intel.com> wrote:
> 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.

All three proposals are thoughtful, and intriguing.

>
> 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

It's an interesting idea, and I think people have mentioned it, but no
one has formally proposed, or I don't remember a formal proposal.

But wouldn't a central registry of prefixes run counter to the needs
for decentralization? Or are you mainly focusing just on the
extensibility aspect?

>
> * 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.
>

One aspect of looking at how to incorporate namespaces into HTML is
that we could use the same functionality for extensibility in both
XHTML and HTML. It does sound like your proposal covers both.

> * 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

Were you thinking then that the browsers and other user agents would
handle these registered prefixes, as "blessed" prefixes? The same as
character entities are handled?

I'm trying to wrap my head around how this proposal will work with the DOM.

> * It allows independent parties to develop useful extensions without the W3C having to act as a choke point to approve stuff
>
>

Speaking of the DOM, how would you see the prefix, namespace handling
being managed in the DOM with your proposal?

And who would manage the registry?

> Apologies if someone has proposed this before.
>
> Thoughts?
>
>
> -Rob
>


Shelley

Received on Saturday, 21 November 2009 00:19:45 UTC