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

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

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