- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 11 Jan 2010 06:04:19 -0800
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>
Hi Shelley, Thanks for your input. On Jan 10, 2010, at 7:10 AM, Shelley Powers wrote: > 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]. It seems to me that neither Doug nor Eliot asked Ian's permission or approval before doing their split, and likewise Ian is not obligated to ask theirs. But ultimately, the Working Group will have to decide which of these Canvas 2D API drafts to proceed with. > > And the split document is confusing. In contains the line: > > "This specification is an HTML specification. All the conformance > requirements, conformance classes, definitions, dependencies, > terminology, and typographical conventions described in the core HTML5 > specification apply to this specification. [HTML5CORE]" > > Actually, it is not an HTML specification. A 2D API is not HTML. And > the document references another document that has already been > rejected by the group, based on the other splits and merges that > happened this week. See my comments on the Communication draft. If and when this document gets to FPWD, we will have a bug component for it, and run the bug/ issue process on the new spec in the usual way. We can even create a component ahead of time, if that would be helpful. Some suitable ways to object to such language in the 2D Context spec would be: - File a bug when/if the 2D Context component is created in bugzilla, and follow up in the usual way. - When/if the document is put forward for FPWD, raise a resolvable objection about this language (e.g. "I object to publication unless the claim that the specification is 'an HTML specification' is removed"). > 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. One thing we now seem to have consensus on is removing the 2D Context API from the main spec. Or at least, no one has objected to this so far. That's great. I believe closing out the bug is the right way to reflect that. What we now need to decide is what document, if any, we'll publish as a replacement. The proper way to decide that is to discuss things and then put forward one or more FPWD resolutions for API drafts. If we find that the authors of both documents want them published and cannot reconcile their differences, then we may resort to the issue process. But the issue process is only for actual controversies, and not to be used speculatively. > > 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. As stated before, we'll only resort to the heavyweight process if both editorial teams want to proceed with FPWD and the Working Group only wants to publish one of the two specs. In other words, only if there is an actual controversy, not speculatively. > 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. If anyone has a concrete objection to either document, then it would be appropriate to raise it. The purpose of the issue process is to resolve actual disputes where the parties feel so strongly that they want to escalate. It is not appropriate to use it as a fishing expedition to flush out objections. > 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. It is a previously recorded Working Group Decision that Canvas (including the 2D API) is in scope for the HTML Working Group. That doesn't mean we *have* to publish it, but it does mean that we have decided that the HTML Working Group is at least one suitable home. Per the W3C Process, that decision can only be revisited if there is new information. That being said, I think our rough consensus (including Doug and Eliot) was to publish a Canvas API spec as an HTML WG work item for now, but consider moving it to a different group at some point in the future. I don't believe there was any concrete effort ongoing to create such a group, but in any case, it is a separate issue from doing the split or which standalone canvas API spec to use. > 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. I don't believe there was any review prior to Doug and Eliot's take at a split, but that's ok, because there has been plenty of opportunity for review since. And review of a concrete document is much more effective than review of an idea. We can apply that same principle to Ian's take at a split. That's the end of my process comments as Chair. -------------- For what it's worth, here's my own take (statements below are personal opinions and not with my chair hat on): 1) My understanding is that we had rough consensus that the Canvas API spec should be revised to include only the CanvasRenderingContext2D interface and related interfaces, but not the element. To date this work has not been done to Doug and Eliot's draft, but Ian's draft makes the split as agreed. 2) Doug and Elitot's draft has not been touched for over two months, since Eliot did his round of revisions. Prior to that, there was another 2 month gap after Doug's original check-in. It seems like Eliot and Doug may have a hard time getting this spec ready for Last Call in a timely manner, given their many other responsibilities. That's not to cast aspersions on them - I have also had the experience of signing up to edit a spec and then finding it a challenge to make the time. 3) Previously, Ian has said that he'll agree to split out CanvasRenderingContext2D if someone else does the work. Now he's showing willingness to do that work himself. I see this as a positive development. 4) There are a number editorial changes I would propose if and when Ian's draft gets to FPWD, to read better as a standalone spec. For example, the SotD section could use revision, and the "1 Conformance Requirements" section is missing the usual introductory material and instead jumps right into defining all the IDL interfaces. However, I am largely satisfied with the technical content. Thus, overall, I see Ian's draft as more likely to deliver a standalone canvas API spec as a timely manner, and therefore I think it would be in the best interests of the WG to go with that draft. However, I think meeting technical requirements, and showing a track record of responsible editorship, is more important than who edits. Thus, if Doug and Eliot's draft is updated to meet requirements and shows a track record of timely editing, then I will not have a strong opinion either way. (Yes, this contradicts my previous concerns about Eliot's editorship, which after further discussion and consideration I have withdrawn.) I would be interested to hear from Doug and Eliot on this issue. Regards, Maciej
Received on Monday, 11 January 2010 14:04:54 UTC