W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 13423] Remove the Editing APIs section. It's extremely incomplete and contradicts my editing spec on a lot of points, so it will confuse implementers.

From: <bugzilla@jessica.w3.org>
Date: Fri, 19 Aug 2011 18:57:12 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QuUFk-0004Rk-5R@jessica.w3.org>

--- Comment #37 from Shelley Powers <shelleyp@burningbird.net> 2011-08-19 18:57:09 UTC ---
(In reply to comment #36)
> Community Groups have a patent policy as well.  In fact, in this respect it's
> even stronger than for regular Working Groups: contributors to CG
> specifications must grant patent licenses *immediately*.  I'm currently waiting
> for TV Raman to agree to the editing CG's terms on behalf of Google.  As soon
> as he does, and I submit my work there, everyone immediately gets a patent
> license to all of Google's contributions to the editing spec, IIUC.
> Moreover, the full request for patent commitments from CG members kicks in at
> Final Specification stage.  This doesn't have the requirements of REC, and can
> be much more frequent.  The editing spec could not plausibly get to REC for a
> few years yet, and implementers would be exposed to patent risk in the interim.
>  In a CG, my current plan is to publish a Final Specification regularly
> (perhaps annually) as a snapshot, so patent protection is available much more
> rapidly than under the normal Process.
> Disclaimer to all of the above: IANAL.  It is up to the parties concerned to
> decide whether they think a CG spec is good enough for them, or if they want a
> full REC-track spec.  I am not ruling out the possibility of eventually
> publishing a copy of the editing spec on the REC track.
> I think this bug has been sorely overused at this point, however.  I think it
> would be best resolved.  The current text in HTML5 is much too vague to even be
> testable and would have to be removed for PR anyway, so I suggest it be removed
> now.  If anyone would like to object at that point, the usual channels are
> available to them.

That's cool, but I still don't understand why this document can't be submitted
as another document within the HTML WG. The group is chartered to cover the
Editing API. Keeping it within the HTML WG ensures expeditious handling. 

Isn't the purpose of the Community groups to facilitate specifications moving
into REC track? The FAQ[1] states as much. Well, here we are, with the document
already to go into a WG as a FPWD. Can't get faster than that.

And I'm still concerned about your discussion of this document. It seems to me
your interest is in keeping the document in a Community Group for the
foreseeable future, and not move the document into the REC track. I don't
believe this was the purpose of the Community Groups. According to the FAQ

"Does the Community Group Process Replace the Recommendation Track?

No. It complements the Recommendation Track and is designed to facilitate
transition to the Recommendation Track. W3C is an ISO/JTC1 PAS Submitter and
only submits W3C Recommendations (not Community Group Reports or other report
types) to ISO."

If the W3C leadership doesn't care that CG members see it as a replacement for
REC track, than I won't. And yes, technically this issue isn't related to this
bug (which is whether the text is removed or not from the HTML5 document). But
I don't know how or where to file a bug or issue on the location of the new
Editing API draft. If the HTML WG can provide directions on where to file a bug
related specifically to the issue putting the Editing API into a community
project rather than as a new HTML WG deliverable, I will do so.

[1] http://www.w3.org/community/about/faq/

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 Friday, 19 August 2011 18:57:13 UTC

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