Re: Proposal for ISSUE-41: Generalization of approach taken by SVG and MathML

On Mar 22, 2010, at 9:57 PM, Ennals, Robert wrote:

> Hi Guys,
>
> Since the initial response seemed generally positive, I have now  
> written up my new change proposal for ISSUE-41.
> You can find it here:
> http://www.w3.org/html/wg/wiki/ChangeProposals/extensionslikesvg

Thank you for your submission. Now recorded at: http://dev.w3.org/html5/status/issue-status.html#ISSUE-041

>
> The intention is that it be a generalization of the model that has  
> already been taken for SVG and MathML. In particular:
>
> ·         All elements introduced by an extension must appear as  
> descendents of a root element (e.g. svg or math)
> ·         A registry is used to coordinate the allocation of root  
> element names, and associate them with namespaces
> ·         A root element MUST contain an xmlns giving the default  
> namespace of the extension – in order to be valid “extended HTML”
> ·         A root element MUST contain an @extension attribute to  
> inform the HTML parser that the xmlns should be obeyed
> ·         If an extension eventually becomes part of HTML, then it  
> is expected that the updated spec will not require the use of the  
> @extension attribute or the xmlns
> ·         To support the above behavior, a user agent that supports  
> an extension should interpret a known root node that has no xmlns or  
> @extension as if both had been present . This allows a user agent to  
> correctly handle documents created in future versions of HTML that  
> make the supported extension standard.
> ·         An extension can also define prefixed attributes that can  
> be applied to elements from other namespaces
> ·         Such a prefix must be declared with an xmlns declaration,  
> and the element that makes that binding MUST have the @extension  
> attribute set, to inform the parser that the prefix should be  
> obeyed, rather than following current HTML parsing
> ·         As with element names, prefixes must be registered, and if  
> a user agent understands an extension, it can infer the namespace  
> for prefixes that it understands
>
> The main rationale is to provide guidelines for the creators of  
> extension specs about how such specs should be written so that they  
> integrate well with HTML, and to provide guidelines for the creators  
> of user agents about what they should expect a document that uses an  
> extension to look like. Authors of extension specs are still  
> STRONGLY encouraged to communicate with the HTML WG to help design  
> their specs better. The aim of this proposal is to provide  
> guidelines about what the author of such a spec should expect from  
> this process, to streamline the process of making specs work with  
> HTML, and to communicate with the external community, including  
> those who, for whatever reason, might not want to talk to the HTML  
> WG, about how one should go about extending HTML.
>
> This proposal is designed to support platform extensions such as SVG  
> and MathML, and language extensions such as RDFa. It could also be  
> used to support vendor-specific extensions, however that is not the  
> primary goal of this proposal.
>
>
> Thoughts? opinions, criticisms, improvements?
>
> -Rob
>
>
>