- From: Ennals, Robert <robert.ennals@intel.com>
- Date: Tue, 24 Nov 2009 06:53:56 +0000
- To: "Ennals, Robert" <robert.ennals@intel.com>, "public-html@w3.org" <public-html@w3.org>
- CC: "Carr, Wayne" <wayne.carr@intel.com>, "Tran, Dzung D" <dzung.d.tran@intel.com>
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