Re: Possible *third* proposal for ISSUE-41 Distributed Extensibility

On Mar 18, 2010, at 3:17 PM, Ennals, Robert wrote:

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

Personally, and in my non-chairing capacity, I like this proposal less  
either of your other two. In particular, I don't like the idea of  
making parsing behavior dependent on an asynchronously updated  
registry. Also, I don't like the idea of a single point of failure  
that, in case of a bad update, could break the whole Web (and other  
Apple applications such as Mail, iChat and iTunes).

Regards,
Maciej



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