W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2009

[Bug 8357] New: Possible Compromise solution for namespaces in HTML5

From: <bugzilla@wiggum.w3.org>
Date: Mon, 23 Nov 2009 22:32:29 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-8357-2486@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8357

           Summary: Possible Compromise solution for namespaces in HTML5
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec proposals
        AssignedTo: dave.null@w3.org
        ReportedBy: robert.ennals@intel.com
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


[This is the same message previously posted to public-html, now reported as a
bugzilla bug.]

[This proposal addresses HTML-WG-ISSUE-41 - distributed extensibility]


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


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 23 November 2009 22:32:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:05 UTC