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: Mon, 15 Aug 2011 22:23:32 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qt5ZE-0006gM-8J@jessica.w3.org>

--- Comment #19 from Aryeh Gregor <ayg@aryeh.name> 2011-08-15 22:23:29 UTC ---
(In reply to comment #17)
> Apple would be hesitant to fork the spec with a separate editor. At the same
> time, we would really like to have W3C Patent Policy protection for the
> contents of this spec. We would much prefer if Google, which has funded the
> drafting of the spec so far, would actively participate in bringing it to the
> W3C rather than merely standing aside while someone else forks. Is it Google's
> policy that anyone who wants IPR protection for this spec, a necessary
> prerequisite is to fork it?

Nothing here is Google's policy, it's my personal decision.

> If it's simply a matter of you personally not wanting to deal with the
> mechanics of preparing Working Drafts and such, then we can probably find a
> co-editor to help with that. But if you are unwilling, for example, to process
> comments in W3C bugzilla or abide by any WG decisions about the spec, then it
> seems like the likely outcome would be a fork, which we would prefer not to do.

There are a number of reasons I'm not enthusiastic about publishing a spec at
the W3C:

* I don't want to have to bother with submitting it, reformatting it, etc. 
This is moot if someone else is willing to do the work for that part, or at
least give me enough pointers that it's not too much work for me to do it.
* I don't like the W3C's copyright policy or publication rules, but also don't
want to have two copies of the spec hanging around (even if they're
substantively the same).  But this is unavoidable if someone is willing to
republish it at the W3C on their own initiative, since I did make it public
* The HTMLWG's decision policy is a huge headache.  This could be avoided by
having the spec published at the WebApps WG, which has far more reasonable
policies.  Given that the draft consists solely of implementer requirements and
I intend to do whatever implementers want, the risk of having to deal with
extra arguments about things I don't think are important is acceptably low.
* I think the W3C's document maturity policies make no sense.  But if someone
is going to publish a W3C version anyway, this is unavoidable.
* People who participate in the W3C just focus way too much on process and
abstract ideals instead of straightforward technical quality.  But that's not
something that's worth forking over, annoying though it may be.

In short, if someone can help me out with how to reformat and submit the draft
to the WebApps WG, I guess I can live with that.  I'm not at all happy with the
way legal rather than technical considerations are dictating how this plays
out, but if Apple and/or Microsoft aren't going to accept a non-W3C spec, I'm
not in much of a position to fight.

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, 15 August 2011 22:23:33 UTC

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