RE: Possible Compromise solution for namespaces in HTML5

David Singer suggested an interesting improvement to this proposal:

Rather than requiring the W3C to maintain its own registry of approved prefixes, we could instead piggy-back on the existing IANA registry for media types, and declare that if someone registered a media type of "<something>/<prefix>+xml" then <prefix> is always bound to the namespace for whatever was registered with the IANA.

In most cases, it seems that the prefixes that people are registering as media types already coincide with the prefixes that people are using for their namespaces. 

This looks like a good idea to me. Definitely good to avoid the overhead of creating another registry, and life will be easier for users if the prefix and media type look roughly the same :-)

It would still be useful to maintain a separate machine readable file mapping each prefix to its namespace and other info, for use by validators, but that should be a much easier task than managing an entire registry.


Thoughts?

-Rob


> -----Original Message-----
> From: Ennals, Robert
> Sent: Monday, November 23, 2009 10:54 PM
> To: Ennals, Robert; 'public-html@w3.org'
> Cc: Carr, Wayne; Tran, Dzung D
> Subject: 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 Wednesday, 25 November 2009 21:05:02 UTC