Re: The Canvas 2D API split

On Mon, Jan 11, 2010 at 12:16 PM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Shelley-
>
> Shelley Powers wrote (on 1/10/10 10:10 AM):
>>
>> There was an original split of the Canvas 2D API[1], and an email list
>> created, supposedly to maintain it[2]. The proposal was created before
>> our change procedure was in place, so the item was left as a bug, and
>> the issue was never cleanly resolved. It just went into some form of
>> trackless limbo.
>>
>> Now, Ian has created a split[3], but there's no connection between it
>> and the previous work, and nothing from the originators of the
>> original split whether they're interesting in supporting one or the
>> other[4].
>
> I do find it odd that Ian split off the Canvas Context from the HTML5 spec
> without discussion about the previous split-off spec, but then I'm sure he
> found it odd that I split off the Canvas API spec without a group decision
> either.
>
> I think that ideally, it should be the group making these decisions, not the
> editors.  At the time I made the original split, there was less formality in
> doing so (in fact, I believe that introducing competing drafts was the
> process suggested by the chairs); now that more clear formal process is in
> place, such alternate specs should be decided and steered by the group.
>
>
>> ...
>> There are now two separate proposed splits, neither of which is
>> tracked, or part of an issue, and neither is there seemingly any path
>> forward in this group to resolve what I perceive to be a disconnect
>> between the original bug, and this week's activity.
>>
>> What II'm proposing is that this bug be grandfathered into the current
>> Change Proposal process, except that rather than muck about with the
>> bug, we create an issue for the split. We ask Adrian Bateman, the
>> originator of the original bug, and Doug Schepers and Eliot Graf if
>> they concur with submitting their original document as a change
>> proposal. We also submit Ian's as an alternative proposal, and we call
>> for a discussion on both, as well as other proposals.
>>
>> We could potentially end up with a merged document as consensus, but
>> right now, we have two documents floating around, neither of which is
>> a FPWD, and neither of which has an official path associated with it.
>> And I'm not terribly sure that either is a document we can live with
>> -- a split of this magnitude should be discussed, and a formal
>> resolution given.
>
> I support a merging of the 2 specs.  Since there are 2 other editors, Ian
> and Eliot, and since I am busy editing other specs, I'm afraid I can't
> devote as much time as I would like to the project.
>
> However, the Canvas 2D API is of great interest to the SVG WG, so we
> definitely intend to provide feedback.  This may come in the form of
> proposed wording or even editing, if needed.
>
>
>> More importantly, we need to determine the proper home for the 2D API.
>> I do not believe the HTML WG is it. I do believe that it should have
>> its own working group, and had thought the effort to create the group
>> was underway.
>
> I strongly disagree with this.  Because of publication history, there has
> already been an IP commitment by all the members of the HTML WG, and
> starting a new group would require all parties to join that WG, in order to
> get the same IP commitment; this is not reasonable.
>
> Also, I believe this would simply slow down the work on the Canvas API,
> which I suspect is not the effect you desire (and is certainly not what the
> majority of the HTML WG wishes).
>
> Forming a new WG is not an approach that should be undertaken lightly; it
> diverts resources and attention that could be spent elsewhere. Please be
> mindful of the work you are asking others to do.  Sometimes forming a new
> group is the best answer; I don't believe that is the case in this instance.
>
> On the other hand, forming a Canvas Task Force within the HTML WG could be a
> productive compromise, and would allow for more focused discussions within
> that TF.  This is a very lightweight process... it does not require any
> approval from the AC or W3M or W3C Team, and only a short charter; it can be
> set up by the Chairs of the HTML WG, if they so desire (I'm happy to help
> with that, if they wish to do so).  We already have a Canvas mailing list,
> public-canvas-api, that can be reused.
>

I am not as familiar with the workings of the W3C, or the various
levels of groupings. I am assuming that the Canvas Task Force is
somewhat equivalent to the Accessibility Task Force? Would the Canvas
Task Force have decision power over Canvas, or does every decision
have to come back to this group?

> The SVG WG believes that splitting the Canvas API out is a positive step
> that will make it easier to reference, reuse, and independently evolve.  We
> are quite happy to reference the Canvas API spec no matter who edits it or
> what group produces it (assuming it meets our needs).
>
>
>> Though I agree with splitting the 2D API out of the HTML document, I
>> don't believe the split should be impulsive, and without review and
>> careful consideration. Or that we allow this seeming disconnect
>> between the past effort and this week's effort to continue.
>
> That seems like a reasonable stance.  I am happy to join in discussions of a
> reconciliation and merger of the specs.  At the same time, let's not inject
> too much overhead into the process; there seems to be general agreement
> (Even among the editors) that a separate Canvas API spec is good, let's
> start from a position of that agreement, and progress from there.
>

As long as there is a way of tracking the results.

If we can no longer use the Issue Tracker in order to ensure that
tasks are assigned, with specific deadlines to meet those tasks, what
do we use?

Right now, if I'm going to write about the Canvas 2D API, I have no
web page I can link as the definitive resource on the topic. That's
OK, momentarily, but how do we ensure this state doesn't continue
indefinitely?

> Regards-
> -Doug Schepers

Shelley

> W3C Team Contact, SVG and WebApps WGs
>

Received on Monday, 11 January 2010 18:34:00 UTC