issue-135 change proposal: canvas context-type registry at the W3C

---------------------------------------------------------------------------
1. Summary
---------------------------------------------------------------------------

A means for formally registering context types for the canvas element has
been identified as a need for HTML5.

With regard to that need, the HTML5 specification currently contains the
following statement:

  New context types may be registered in the WHATWG Wiki CanvasContexts page.
  http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element

I propose that instead of that means (registering new context types in the
WHATWG Wiki), the spec be changed to instead reference a registry following
the precedent of the XPointer scheme registry[1], and in a way similar to
the proposed registry for rel tokens outlined in Henri Sivonen's "Rel
Registry at the W3C" proposal[2] for HTML WG issue 27.

  [1] http://www.w3.org/2005/04/xpointer-schemes/
  [2] http://www.w3.org/html/wg/wiki/ChangeProposals/RelRegistryAtTheW3C

---------------------------------------------------------------------------
2. Rationale
---------------------------------------------------------------------------

Having the spec reference a canvas context-type registry at the WHATWG Wiki
has met with some objections, as recorded initially in HTML WG bug
10921[3], subsequently in issue 135[4], and finally in Steven Faulkner's
"Add link to Canvas 2d context spec"[5] for issue 135.

  [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10921
  [4] http://www.w3.org/html/wg/tracker/issues/135
  [5] http://www.w3.org/html/wg/wiki/ChangeProposals/RelRegistryAtTheW3C

In addition, a Wiki -- regardless of where it is hosted -- is a suboptimal
means for maintaining a formal registry of any kind, and should be avoided
if better means are available. And better means are available -- namely,
a mechanism similar to the XPointer scheme registry, as proposed here.

The primary advantage that has been suggested for the Wiki-based registry
for new context types is that it provides a low barrier of entry for
registering them. A mechanism similar to the XPointer scheme registry
provides that same low barrier of entry; in fact, it is at least as easy to
use for registering new context types as a Wiki mechanism, if not easier.

Also, as Henri notes in his "Rel Registry at the W3C" change proposal:

  - "The W3C is already in the registry business in the form of the
    XPointer scheme registry, so there's both process precedent and
    existing software for implementing a registry at the W3C"

  - This registry-hosting scenario provides for maintenance "on a site with
    multiple sysadmins responding to failure situations and with more
    resources to enable the longevity of the registry URL."

---------------------------------------------------------------------------
3. Details
---------------------------------------------------------------------------

Step 1. Deploy a canvas context-type registry at the W3C. 

The logistics of deploying the registry would be similar to those outlined
in the Details section of the "Rel Registry at the W3C" change proposal:

  http://www.w3.org/html/wg/wiki/ChangeProposals/RelRegistryAtTheW3C#Details

Step 2. Change the spec to reference the registry instead of the Wiki.

After the canvas context-type registry has actually been deployed, update
the HTML5 spec to reference it instead of the Wiki. Specifically, take the
following statement:

  New context types may be registered in the _WHATWG Wiki CanvasContexts page_.

...and replace it with this statement:

  New context types may be registered in the _canvas context-types registry_.

...where _canvas context-types registry_ is a hyperlink to the new registry.

---------------------------------------------------------------------------
4. Positive Effects
---------------------------------------------------------------------------

  - Extremely low barrier of entry for registering new canvas context types

  - The registry will be maintained on a site with multiple sysadmins
    responding to failure situations and with more resources to enable the
    longevity of the registry URL.

---------------------------------------------------------------------------
5. Negative Effects
---------------------------------------------------------------------------
None.

---------------------------------------------------------------------------
6. Conformance-class changes
---------------------------------------------------------------------------
None.

---------------------------------------------------------------------------
7. Risks
---------------------------------------------------------------------------
None.

-- 
Michael[tm] Smith
http://people.w3.org/mike

Received on Friday, 11 March 2011 02:27:24 UTC