Possible *third* proposal for ISSUE-41 Distributed Extensibility

Hi Guys,

I'm thinking of writing up a *third* proposal for ISSUE-41.

This one is strongly based on Liam Quinn's earlier proposal, but tries to fix some of the issues that people raised with this. The main change is that while Liam's proposal allows a document to link to whatever namespace mapping file it likes, this proposal has a single such namespace mapping file maintained by the W3C, and every user agent is required to maintain a local copy, which it periodically updates using whatever vendor-specific technique is appropriate.

The essence is:

Extensions with W3C registered prefix associations with namespaces

*         There is a single registry, maintained by the W3C, that maps registered prefixes to fixed namespaces, where anyone can register a prefix and associated namespace

*         A valid HTML file MUST use xmlns:prefix to specify the namespace of any prefix that it uses.  The prefix associated with a namespace MUST be the same as specified in the registry.

*         If a document omits the xmlns:prefix then the document is technically invalid, but a user agent that implements the feature should act as if the correct prefix had been filled in.

*         Registered prefixes MUST NOT being with "x-", with that reserved to prevent name clashes with experimental uses of prefixes that do not register.

Extensions moved into HTML without prefixes

*         There is also a single namespace mapping file, maintained by the W3C, for components adopted into HTML by the W3C.  That registry provides information  for automatically assigning a namespace to an element that would otherwise have no namespace.  Rules applied to use this information would determine the namespace of a node based on its name, and any elements it was inside.  Examples are inclusion of SVG and MathML in HTML files without the need for prefix to specify the associated namespace. [Unlike Liam's proposal, there is only one such rule set, and a document cannot link to an alternative one]

*         Any user agent would be required to periodically update its local copy of this namespace mapping file, using a method appropriate to the user agent, in order to claim to be a valid HTML5 user agent.

*         Since the namespace mapping file is updated fairly infrequently, the user agent would not be required to have an exactly up-to-date version, and parsing would not be blocked while updating. The namespace mapping file could contain an expiration date with the requirement to refresh any local copies of the file before that date.

*         When a feature becomes part of HTML, the namespace mapping file is updated to allow use of those tags without a prefix. Since all user agents are required to update their local copies of this namespace mapping file, this will also allow the tags to be used without a prefix in older user agents too.

*         If there is a clash between a name used in a component being added to html and a name already used in html, then the namespace mapping file may keep the prefix just for that name clash. If HTML renames a name in an extension to avoid a name clash, then the namespace mapping file can also specify this synonym, allowing older user agents to understand the use of the new synonym as if it was an occurrence of the old name. Writers of extension specs are STRONGLY encouraged to communicate with the working group to avoid this happening.

Experimental features without prefix registration

*         For vendor-specific, enterprise-specific, and highly experimental features, one can instead use a prefix beginning with "x-" and not make an entry in the W3C registry.  xmlns must be used to define the prefix in the html file. As with registered extensions, such namespaces may also be eventually folded into core HTML, and an unregistered extension may evolve into a registered extension, with both prefixes mapping to the same namespace.

General

*         One is allowed to write createElement("prefix:name") and the prefix will be automatically resolved to a namespace based on the registry.

*         All extensions are strongly encouraged to use attributes on top of existing HTML elements, rather than new elements, where possible, to provide more graceful fallback

Advantages:

*         This is compatible with XML namespaces

*         Extensions that are not part of core HTML are visibly distinguished, making it clear to an author what is or is not a standard HTML feature

*         The namespace mapping registry removes the need for us to support legacy prefixes after a feature has been folded into HTML, since older user agents will support the name without its prefixes once they update their configuration file

Disadvantages:

*         This requires changing HTML5 parsing behavior. Names with a prefix will now be split into prefix and localname, rather than the ":" just being part of the name.

*         The same user agent will parse the same document differently, depending on how recently they updated their namespace mapping registry. However this only affects unprefixed tags that a user agent otherwise didn't recognize - which can act as a hint that the user agent should asynchronously check for an updated registry.

*         Extensions are allowed to define new element types, however the ability to remap namespaces makes this less of a problem than it would be otherwise.


Comments?
If it seems that people might like this then I'll write it up formally.


-Rob