I disagree with this move. 

This is a major change to the document. It comes after the editor of this new subspec had already agreed that HTML5 was Last Call quality--which we have to assume means that he seemingly thought this section was just fine a little while ago. 

The new specification isn't available for input within the W3C. It's not even being managed by the W3C, and the editor has made it clear he is indifferent about both the W3C and the W3C procedures.

I would also like to remind people about others impacted by HTML.

I realize that the browser companies have become indifferent to the users, but I hope the W3C doesn't share this indifference. 

This move is going to cause confusion to the end users (authors and web developers) and other application developers dependent on this section.

mass-move component to LC1

I can leave the old buggy text in the W3C copy if that's what the working group wants. I agree that my old text should be removed from the WHATWG copy though now that we have a better version actively being maintained. cc'ing chairs for advice.

(In reply to comment #4)
> I can leave the old buggy text in the W3C copy if that's what the working group
> wants. I agree that my old text should be removed from the WHATWG copy though
> now that we have a better version actively being maintained. cc'ing chairs for
> advice.

When people joined the W3C, and the HTML WG, they made a commitment to work as part of a team, and that their work would become part of the team's work. In my opinion, Aryeh should have approached the HTML WG, as a true team member, with his work and a proposal to split the editing API out. His effort would most likely have been gratefully accepted. 

Evidently, he decided another course. However, that has nothing to do with the _technology_, so...

The text must remain in HTML5 until the WG decides to split it out, or do whatever.

Shelley, I appreciate your viewpoint, but since you're not a working group member I don't think you can really speak for the group. I would like to hear from working group members what they think should happen here.

(In reply to comment #6)
> Shelley, I appreciate your viewpoint, but since you're not a working group
> member I don't think you can really speak for the group. I would like to hear
> from working group members what they think should happen here.

Hey, I'm part of the community of HTML users, and I do have a right to make a statement. 

This is LC, which means the community outside of the HTML WG is asked to make a comment. My comment is I have no interest in parts of HTML (and its associated APIs) being managed by the W3C, and other parts being managed by a self-selected closed group with little or no accountability to the web community.

WG Member here. If the existing text is a subset of what is being implemented, that's no different to the rest of the frozen W3C spec. But if it contradicts what is being implemented to the extent that clientside code written against the spec will fail, that will cause authors confusion and users may experience breakage. (Implementor feedback would be valuable as to which is the case here.)

I don't think we should leave such contradictions in the spec. I'm ambivalent about whether that's corrected by fixing the HTML draft itself, by splitting it out into a second HTML WG document, or by making it a Webapps responsibility. Our WG charter suggests any of these options would be fine, but editing APIs were supposed to be one of our deliverables.

Worst case scenario: if nobody volunteers to maintain this text within the W3C space, I'd still rather we remove the text containing the contradictions.

Just my 2 cents.

My own personal preference (not speaking as Chair) would be to have Aryeh's text submitted to the W3C in some form (either to the HTML WG or the Web Apps WG). I believe if that occurred, there would be no controversy about removing the buggy/incomplete editing spec text from the HTML5 spec.

(In reply to comment #4)
> cc'ing chairs for advice.

My first reaction is that this bug is INVALID as it does not provide "A clear statement of a problem with the specbug reports are more useful if they identify concrete problems."  Furthermore "Only one issueplease use separate bugs for separate issues.".  Instead it provides, and only provides, "one suggested way to solve the problem".

If a clear statement of the problem is provided, I would have no problem with this proceeding to be resolved as FIXED.  If that is done, if somebody wishes to write a concrete proposal which addresses the issue, they can mark the bug with the TrackerRequest keyword.

(In reply to comment #10)
> (In reply to comment #4)
> > cc'ing chairs for advice.
> 
> My first reaction is that this bug is INVALID as it does not provide "A clear
> statement of a problem with the spec�bug reports are more useful if they
> identify concrete problems."  Furthermore "Only one issue�please use separate
> bugs for separate issues.".  Instead it provides, and only provides, "one
> suggested way to solve the problem".
> 
> If a clear statement of the problem is provided, I would have no problem with
> this proceeding to be resolved as FIXED.  If that is done, if somebody wishes
> to write a concrete proposal which addresses the issue, they can mark the bug
> with the TrackerRequest keyword.

I do not think this particular item fits within the overly simple "submit bug, do change proposal" process.

(In reply to comment #9)
> My own personal preference (not speaking as Chair) would be to have Aryeh's
> text submitted to the W3C in some form (either to the HTML WG or the Web Apps
> WG). I believe if that occurred, there would be no controversy about removing
> the buggy/incomplete editing spec text from the HTML5 spec.

I did want to say, though I'm not an HTML WG member, that I agree 100% with this. I think this is an elegant solution and a win/win for everyone.

(In reply to comment #8)
> WG Member here. If the existing text is a subset of what is being implemented,
> that's no different to the rest of the frozen W3C spec. But if it contradicts
> what is being implemented to the extent that clientside code written against
> the spec will fail, that will cause authors confusion and users may experience
> breakage. (Implementor feedback would be valuable as to which is the case
> here.)

The existing text is so sketchy that it's almost useless for interoperability.  I think leaving it in would be confusing, but not likely to cause implementations to diverge appreciably.

(In reply to comment #9)
> My own personal preference (not speaking as Chair) would be to have Aryeh's
> text submitted to the W3C in some form (either to the HTML WG or the Web Apps
> WG). I believe if that occurred, there would be no controversy about removing
> the buggy/incomplete editing spec text from the HTML5 spec.

As I've said several times, my spec is in the public domain (CC0) and anyone who wants to submit it to the W3C is free to do so.  I won't stop them.

This is an excellent opportunity for those who believe that the W3C is a good place to develop specs to show their willingness to improve the web.  All it would take is a modest amount of effort to submit the spec for W3C publication, and of course in their view, this would be beneficial because the W3C is a good place to publish specs.  I wait with interest for one of the many people who have expressed concern about the editing spec not being at the W3C to spend the necessary time themselves to fix the problem, rather than expecting others to do it.

(In reply to comment #10)
> My first reaction is that this bug is INVALID as it does not provide "A clear
> statement of a problem with the specbug reports are more useful if they
> identify concrete problems."  Furthermore "Only one issueplease use separate
> bugs for separate issues.".  Instead it provides, and only provides, "one
> suggested way to solve the problem".

As far as I read the Decision Policy, the criteria it gives for bug filing are purely advisory.  It says only "bug reports that do not have enough information to identify a problem or potential action may be closed as INVALID."  I interpret this as saying that although the editor is likely to close such bugs as INVALID, this is not a requirement or even a suggestion, just a prediction.  If the editor feels this bug report contains sufficient information to be actionable, he is entitled to resolve it as FIXED in his sole discretion, subject only to the usual escalation procedures.

Do you disagree with my interpretation of the policy?

(In reply to comment #12)
> I did want to say, though I'm not an HTML WG member, that I agree 100% with
> this. I think this is an elegant solution and a win/win for everyone.

Are you volunteering to do the work to submit the spec to the W3C?  If not, do you know of anyone who would be willing to do so?  It's all very well to propose that as a solution, but it doesn't help much if no one cares to do it.

(In reply to comment #13)
> (In reply to comment #8)
> > WG Member here. If the existing text is a subset of what is being implemented,
> > that's no different to the rest of the frozen W3C spec. But if it contradicts
> > what is being implemented to the extent that clientside code written against
> > the spec will fail, that will cause authors confusion and users may experience
> > breakage. (Implementor feedback would be valuable as to which is the case
> > here.)
> 
> The existing text is so sketchy that it's almost useless for interoperability. 
> I think leaving it in would be confusing, but not likely to cause
> implementations to diverge appreciably.
> 
> (In reply to comment #9)
> > My own personal preference (not speaking as Chair) would be to have Aryeh's
> > text submitted to the W3C in some form (either to the HTML WG or the Web Apps
> > WG). I believe if that occurred, there would be no controversy about removing
> > the buggy/incomplete editing spec text from the HTML5 spec.
> 
> As I've said several times, my spec is in the public domain (CC0) and anyone
> who wants to submit it to the W3C is free to do so.  I won't stop them.
> 
> This is an excellent opportunity for those who believe that the W3C is a good
> place to develop specs to show their willingness to improve the web.  All it
> would take is a modest amount of effort to submit the spec for W3C publication,
> and of course in their view, this would be beneficial because the W3C is a good
> place to publish specs.  I wait with interest for one of the many people who
> have expressed concern about the editing spec not being at the W3C to spend the
> necessary time themselves to fix the problem, rather than expecting others to
> do it.
> 
> (In reply to comment #10)
> > My first reaction is that this bug is INVALID as it does not provide "A clear
> > statement of a problem with the spec�bug reports are more useful if they
> > identify concrete problems."  Furthermore "Only one issue�please use separate
> > bugs for separate issues.".  Instead it provides, and only provides, "one
> > suggested way to solve the problem".
> 
> As far as I read the Decision Policy, the criteria it gives for bug filing are
> purely advisory.  It says only "bug reports that do not have enough information
> to identify a problem or potential action may be closed as INVALID."  I
> interpret this as saying that although the editor is likely to close such bugs
> as INVALID, this is not a requirement or even a suggestion, just a prediction. 
> If the editor feels this bug report contains sufficient information to be
> actionable, he is entitled to resolve it as FIXED in his sole discretion,
> subject only to the usual escalation procedures.
> 
> Do you disagree with my interpretation of the policy?
> 
> (In reply to comment #12)
> > I did want to say, though I'm not an HTML WG member, that I agree 100% with
> > this. I think this is an elegant solution and a win/win for everyone.
> 
> Are you volunteering to do the work to submit the spec to the W3C?  If not, do
> you know of anyone who would be willing to do so?  It's all very well to
> propose that as a solution, but it doesn't help much if no one cares to do it.


I'm actually not a member of the W3C. And I won't be as long as there are limitations on my joining that exceed those for others. 

Are you saying you've quit the W3C and the HTML WG?

I am still a member in good standing of the HTMLWG, as a representative of Google, as stated here:

http://www.w3.org/2000/09/dbwg/details?group=40318&public=1

I don't see the relevance of this fact to the discussion at hand, however.  In particular, per the HTMLWG Charter:

"""
The co-chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.
"""
http://www.w3.org/2007/03/HTML-WG-charter.html#participation

As I am neither a co-chair nor an editor, I'm puzzled as to why you think that my membership in the HTMLWG implies any obligation to commit time to submit a specification to the W3C, or precludes me from working on specifications outside the W3C.

However, I will not respond further in this vein on this bug, out of consideration for the various people who are watching it out of technical interest and would find this discussion a distraction.  If you would like to discuss questions such as this with me, I suggest you either e-mail me directly and CC www-archive, or bring it up someplace else like Google+.

(In reply to comment #14)
> 
> I'm actually not a member of the W3C. And I won't be as long as there are
> limitations on my joining that exceed those for others. 

I've responded here:

http://lists.w3.org/Archives/Public/www-archive/2011Aug/0015.html

- Sam Ruby

(In reply to comment #13)

> 
> (In reply to comment #9)
> > My own personal preference (not speaking as Chair) would be to have Aryeh's
> > text submitted to the W3C in some form (either to the HTML WG or the Web Apps
> > WG). I believe if that occurred, there would be no controversy about removing
> > the buggy/incomplete editing spec text from the HTML5 spec.
> 
> As I've said several times, my spec is in the public domain (CC0) and anyone
> who wants to submit it to the W3C is free to do so.  I won't stop them.
> 
> This is an excellent opportunity for those who believe that the W3C is a good
> place to develop specs to show their willingness to improve the web.  All it
> would take is a modest amount of effort to submit the spec for W3C publication,
> and of course in their view, this would be beneficial because the W3C is a good
> place to publish specs.  I wait with interest for one of the many people who
> have expressed concern about the editing spec not being at the W3C to spend the
> necessary time themselves to fix the problem, rather than expecting others to
> do it.

(With my vendor rep hat on: )

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?

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.

(In reply to comment #17)
> (In reply to comment #13)
> 
> > 
> > (In reply to comment #9)
> > > My own personal preference (not speaking as Chair) would be to have Aryeh's
> > > text submitted to the W3C in some form (either to the HTML WG or the Web Apps
> > > WG). I believe if that occurred, there would be no controversy about removing
> > > the buggy/incomplete editing spec text from the HTML5 spec.
> > 
> > As I've said several times, my spec is in the public domain (CC0) and anyone
> > who wants to submit it to the W3C is free to do so.  I won't stop them.
> > 
> > This is an excellent opportunity for those who believe that the W3C is a good
> > place to develop specs to show their willingness to improve the web.  All it
> > would take is a modest amount of effort to submit the spec for W3C publication,
> > and of course in their view, this would be beneficial because the W3C is a good
> > place to publish specs.  I wait with interest for one of the many people who
> > have expressed concern about the editing spec not being at the W3C to spend the
> > necessary time themselves to fix the problem, rather than expecting others to
> > do it.
> 
> (With my vendor rep hat on: )
> 
> 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?
> 
> 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.

I've been informed indirectly that there are no additional limitations on my joining the W3C. That's good to know.

I'll make an offer: if Aryeh needs the help, I'll offer to help co-edit. I'd offer to take on all editing, but I'm just not familiar with the whole process and would prefer to take a junior position for this first effort, so someone can show me how it all works. 

I would be more than willing to answer the Bugzilla bugs. And I would promise to abide by the WG decisions, even if I don't agree. I can also take on the mechanics of getting this incorporated into the W3C, if I could get help from someone like Michael.

(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 domain.
* 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.

Ok so I have created a version of the editing API spec in the W3C space
http://dev.w3.org/html5/editing-api/Overview.html

I am happy to help maintain it if needed. I am equally happy to remove it or have it removed if it is deemed unhelpful.

Question for Maciej (and sorry to everyone for abusing this bug for process discussions): would it be acceptable to Apple if this is published in a W3C Community Group <http://www.w3.org/community/> for now instead of in an actual Working Group?  I would find it much more palatable to work in a Community Group than in a group governed by the full Process.

Community Groups are not governed by the patent policy, so I would expect that when the draft is more mature I would move it to the WebApps WG.  The patent policy only applies to Recommendations, so it should make no difference to patents if it's not REC-track right away.  My understanding is that it's supposed to be easy to move specs from Community Groups to regular Working Groups once they mature.

One reason to prefer not putting the spec on REC track right away is that it can retain its current copyright status without issue.  This means I won't need to publish a separate specification (à la http://dom.spec.whatwg.org) to make the copyright status clear: I'll redirect my existing specification URL to the W3C Community Group one.  Having only one spec URL will reduce confusion for the time being.

I also would like to test out and support the Community Group mechanism in general.  I think it's an important step forward for the W3C and could solve a lot of its institutional problems if it were expanded a bit.  I'm actually not committed to the downfall of the W3C here, I just think it has a lot of problems in practice, and Community Groups solve most of them.

So at this point, I would like to submit this for work in a W3C Community Group, not have any version on the W3C REC track, and submit it to the REC track when it's more mature and is close to being ready for Last Call.  This should not materially affect the Patent Policy's applicability, AIUI.  Would this be okay with Apple, assuming the Community Group proposal is accepted?

Does it make sense to pull a section from a Rec track document that has already entered into Last Call, and then pull it into the incubator group? A group that isn't covered by patent policy and doesn't necessarily guarantee the item will end up on the Rec track?

I feel we've taken two steps back.

There needs to be a clear understanding of what this move means, because frankly, it has more than a whiff of "amateur hour"--people stumbling about, not understanding what it means for a document to be in Last Call, and not understanding how this new incubator group co-exists with the W3C's more formalized effort. 

As has been noted, I'm not a member of the HTML WG, but I'm very concerned that the HTML5 document is not LC quality and the move to LC was a political one, not one based on sound technical principals. The effort associated with the editing section of the document only justifies this concern.

Until this confusion about the incubator group and pulling in a section from a LC document is resolved (not glossed over), I continue my objection to removing this section from the HTML5 document. I really do think we in the web community have a right to insist that the W3C, generally, and the HTML WG specifically, ensure a more professional approach is taken regarding the HTML5 document from this point in.

(Just an opinion, but Aryeh, I think you need to have a chat with Google about your work with the W3C, because you seem to be confused about Google's relationship with the W3C and how it impacts on your work. Normally I wouldn't care, but yanking this section out of the HTML5 document is disruptive to the broader web community.)

(In reply to comment #22)
> Until this confusion about the incubator group and pulling in a section from a
> LC document is resolved (not glossed over), I continue my objection to removing
> this section from the HTML5 document.

I'm willing to write a Change Proposal defending the removal of these sections.

> Just an opinion, but Aryeh, I think you need to have a chat with Google about
> your work with the W3C, because you seem to be confused about Google's
> relationship with the W3C and how it impacts on your work.

The person at Google who oversees my work is Ian Hickson.  If you think I misunderstand my work obligations, I advise you to take it up with him.

(In reply to comment #23)
> (In reply to comment #22)
> > Until this confusion about the incubator group and pulling in a section from a
> > LC document is resolved (not glossed over), I continue my objection to removing
> > this section from the HTML5 document.
> 
> I'm willing to write a Change Proposal defending the removal of these sections.

And I'm willing to issue a formal objection if this proceeds without a clear understanding of what it means to take something from the Rec track and put it into the W3C's new incubator effort. 

> 
> > Just an opinion, but Aryeh, I think you need to have a chat with Google about
> > your work with the W3C, because you seem to be confused about Google's
> > relationship with the W3C and how it impacts on your work.
> 
> The person at Google who oversees my work is Ian Hickson.  If you think I
> misunderstand my work obligations, I advise you to take it up with him.

No, I'm sure you're more than aware of your work obligations. And that you exercise your obligations with due diligence and excellent technical ability. 

My main concern is that if there's going to continue being an issue about copyright and patent for all the work you do for Google, then there will continue to be a problem with any work you do within the W3C. 

I'm not speaking for the W3C in this, but as a member of the web community. Are we going to have problems implementing anything you help spec? Are we going to have issues with Google at some time in the future?

(In reply to comment #24)
> 
> And I'm willing to issue a formal objection if this proceeds without a clear
> understanding of what it means to take something from the Rec track and put it
> into the W3C's new incubator effort. 

You can't object to "proceeding", in particular, you can't object to the opening of a bug report or even to the initial resolution proposed by an editor, which I will note hasn't even happened yet.

You can object to a decision[1].  For that to happen, there will need to be an initial resolution, an issue raised, an opportunity for people to prepare change proposals, and ultimately a decision.  At a minimum, that process will ensure that the Director has the input of the WG on the matter, including a list of concrete proposals to chose from.

My may be able to object to the creation of a community group -- I honestly don't know as the WG was not involved in that action.

In any case, a Formal Objection is likely to be unnecessary in this instance as Editing APIs are called out in the charter, and therefore the topic will undoubtedly come up.

[1] http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews
[2] http://www.w3.org/2007/03/HTML-WG-charter.html

(In reply to comment #25)
> (In reply to comment #24)
> > 
> > And I'm willing to issue a formal objection if this proceeds without a clear
> > understanding of what it means to take something from the Rec track and put it
> > into the W3C's new incubator effort. 
> 
> You can't object to "proceeding", in particular, you can't object to the
> opening of a bug report or even to the initial resolution proposed by an
> editor, which I will note hasn't even happened yet.
> 
> You can object to a decision[1].  For that to happen, there will need to be an
> initial resolution, an issue raised, an opportunity for people to prepare
> change proposals, and ultimately a decision.  At a minimum, that process will
> ensure that the Director has the input of the WG on the matter, including a
> list of concrete proposals to chose from.

OK, that's cool.  

> 
> My may be able to object to the creation of a community group -- I honestly
> don't know as the WG was not involved in that action.
> 
> In any case, a Formal Objection is likely to be unnecessary in this instance as
> Editing APIs are called out in the charter, and therefore the topic will
> undoubtedly come up.
> 


I definitely agree with separating out the editing API from HTML5, and perhaps publishing it as another document in the HTML WG. But completely taking it out of the group, and off the Rec track...this move just doesn't make sense. 

So what is happening next and where, Sam?

> [1] http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews
> [2] http://www.w3.org/2007/03/HTML-WG-charter.html

(In reply to comment #26)
> 
> So what is happening next and where, Sam?

This is a topic for tomorrow's telecon (10b):

http://lists.w3.org/Archives/Public/public-html-wg-announce/2011JulSep/0012.html

But more importantly, the next step is for the editor to propose an initial resolution to this bug, which will occur here in bugzilla.

(In reply to comment #27)
> (In reply to comment #26)
> > 
> > So what is happening next and where, Sam?
> 
> This is a topic for tomorrow's telecon (10b):
> 
> http://lists.w3.org/Archives/Public/public-html-wg-announce/2011JulSep/0012.html
> 

Good to hear.

> But more importantly, the next step is for the editor to propose an initial
> resolution to this bug, which will occur here in bugzilla.

Actually, not quite.

The issue is less separating the Editing API out of the HTML5 spec, and more about where the separated spec will live. 

I really don't think this is a decision that the HTML5 editor can make unilaterally.

Sam: My plan is to remove the sections that are superseded by Aryeh's draft. That will be happening regardless on the WHATWG side. I'm happy to leave these sections in the W3C side (unmaintained, of course) if the working group would like, but I assume that won't be necessary since only Shelley seems to want that course of action and she's not a working group member. Your advice on the matter is welcome. In the absence of specific advice one way or the other, I'll just remove the text in both the WHATWG and W3C copies.

On the long term (years, not months) I expect the text will eventually be merged back in, since it is an integral part of HTML and HTML's APIs, but that's mostly an administrative matter for the future. At this juncture having the text merged in is impractical.

(In reply to comment #29)
> Sam: My plan is to remove the sections that are superseded by Aryeh's draft.
> That will be happening regardless on the WHATWG side. I'm happy to leave these
> sections in the W3C side (unmaintained, of course) if the working group would
> like, but I assume that won't be necessary since only Shelley seems to want
> that course of action and she's not a working group member. Your advice on the
> matter is welcome. In the absence of specific advice one way or the other, I'll
> just remove the text in both the WHATWG and W3C copies.
> 
> On the long term (years, not months) I expect the text will eventually be
> merged back in, since it is an integral part of HTML and HTML's APIs, but
> that's mostly an administrative matter for the future. At this juncture having
> the text merged in is impractical.

I am a member of the community. You all deemed HTML5 mature enough for LC and for comments from the community. Evidently, this wasn't so.

I have no problems with removing this section, and keeping it out of HTML5, where it never did belong.

The issue is where the split document will go, and this shouldn't be your decision at all. It should be the group's decision. Or perhaps a W3C leadership decision.

Aryeh wants to put the document into the new W3C incubator purely because of copyright issues, if I understand him correctly. If I understand the W3C incubator FAQ, the same copyright policy applies to the incubator effort as does the WG efforts. 

The real key is, is Google going to be a problem from now on? If the W3C is going to have problems with Google and copyright issues, then the community that will implement the specs (and not just browser companies) will most definitely have problems with copyright issues--or more appropriately, patent issues. 

So I have no objections to removing the section from the document--even though supposedly the HTML5 editor seems to be indifferent to the opinion of a member of the web community at large. But where the text goes does matter, and why it was moved to the incubator project is especially important. 

I'm assuming the new incubator project was intended to open up working areas and encourage participation from people like me, who are not members of the W3C. I don't believe it was intended because a member company such as Google may want to play fast and loose with patents at some point.

(In reply to comment #29)
> I'm happy to leave these
> sections in the W3C side (unmaintained, of course) if the working group would
> like

I disagree that any text that remains would be unmaintained. Any content that remains in the W3C document is a valid subject of bug reports; and any such bug reports are expected to be RESOLVED by the editor, such resolutions can be escalated, and we will expect any decisions (amicable or otherwise) that result from any such escalations that may occur to be applied.

> Your advice on the
> matter is welcome.

Since this is a charter issue, this will ultimately need to be decided by W3C staff, though the co-chairs will work to ensure that the WG has ample opportunity to provide input on the matter.

Not specific to this matter, I expect that as we move to CR we will find other features that aren't ready to standardize just yet, and such will need to be deferred to HTML.next.  Normally, I would expect to find that through formal testing and an inability to demonstrate the existence of multiple inter-operable implementations.  This particular case seems to simply have been found earlier and through inspection and ad hoc testing, but that's certainly OK too.

(In reply to comment #30)
> 
> Aryeh wants to put the document into the new W3C incubator purely because of
> copyright issues, if I understand him correctly. 

Please stop imputing motives.  It's not germane.


> If I understand the W3C
> incubator FAQ, the same copyright policy applies to the incubator effort as
> does the WG efforts. 

It's not an "Incubator Group", it's a Community Group.  And no, the patent policy is different.


> The real key is, is Google going to be a problem from now on? 

A problem?  What's the problem with Google *paying someone money* to do good work, which they make available to the community (including W3C)?


> If the W3C is
> going to have problems with Google and copyright issues, then the community
> that will implement the specs (and not just browser companies) will most
> definitely have problems with copyright issues--or more appropriately, patent
> issues. 

Aryeh has made it clear that his spec is under an open license, and that W3C (or anyone else) can use it.  How could W3C have a problem with that?

As far as patents, the Community Groups have their own patent commitment policy, and work from the CGs can more effectively move into the Recommendation track to gather even more patent commitments from more members, who can more accurately judge what their commitments would be because the scope of the work is already well-defined.

So, neither one of these statements is correct... in fact, I would say just the opposite.


> I'm assuming the new incubator project was intended to open up working areas
> and encourage participation from people like me, who are not members of the
> W3C. I don't believe it was intended because a member company such as Google
> may want to play fast and loose with patents at some point.

The new Community Group activity was structured for both purposes: to make it easier for the wider community to participate more fully, and to make a lighter-weight manner for our members to participate and build momentum for a topic or technology.  We consulted with our members when forging the patent policy. 

Why would W3C, a member organization, make a project that our members can't participate in? How would that be fair or inclusive?


Personally, I'm very glad to see a more modular approach to incrementally improving HTML, rather than the single-editor monolithic approach we have now, and I'm grateful to Aryeh for all the work he's done on this, and for starting a Community Group around it.  It looks like good technical work, and that's the chief basis on which this effort should be judged.

(In reply to comment #32)
> (In reply to comment #30)
> > 
> > Aryeh wants to put the document into the new W3C incubator purely because of
> > copyright issues, if I understand him correctly. 
> 

> Please stop imputing motives.  It's not germane.

And I said, "if I understand him correctly". 

Please do not lecture me. We've had this discussion before. 

> 
> 
> > If I understand the W3C
> > incubator FAQ, the same copyright policy applies to the incubator effort as
> > does the WG efforts. 
> 
> It's not an "Incubator Group", it's a Community Group.  And no, the patent
> policy is different.
> 
> 
> > The real key is, is Google going to be a problem from now on? 
> 
> A problem?  What's the problem with Google *paying someone money* to do good
> work, which they make available to the community (including W3C)?
> 
>

It is a problem if Google is not going to abide by its agreement with the W3C. 

I am not the only person in this thread who has expressed some concern on this.

"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?"

This isn't impugning Aryeh's effort, or Google. However, the recent moves do bring up questions, and do generate legitimate concerns. We have a right to express these concerns.
 
My primary concern was about the material being outside of the W3C in its entirety, or having to be forked somehow, which didn't make a lot of sense. 

My concern now is that this material was originally in a LC document on a Rec track, and is now being taken to this community or whatever group--which to me, causes a lot of unnecessary confusion.

As has been noted elsewhere, the Editing API was actually part of the HTML WG Charter. Now it seemingly exists as part of a Community group. I don't think the Community Groups were intended as a bypass of traditional W3C working groups.

 
> > If the W3C is
> > going to have problems with Google and copyright issues, then the community
> > that will implement the specs (and not just browser companies) will most
> > definitely have problems with copyright issues--or more appropriately, patent
> > issues. 
> 
> Aryeh has made it clear that his spec is under an open license, and that W3C
> (or anyone else) can use it.  How could W3C have a problem with that?
>

Because copyright has nothing to do with patents, and patent rights are the big concern. 

 
> As far as patents, the Community Groups have their own patent commitment
> policy, and work from the CGs can more effectively move into the Recommendation
> track to gather even more patent commitments from more members, who can more
> accurately judge what their commitments would be because the scope of the work
> is already well-defined.
> 
> So, neither one of these statements is correct... in fact, I would say just the
> opposite.
> 
>

All this tells me is that my concern is more justified, rather than less.
 
> > I'm assuming the new incubator project was intended to open up working areas
> > and encourage participation from people like me, who are not members of the
> > W3C. I don't believe it was intended because a member company such as Google
> > may want to play fast and loose with patents at some point.
> 
> The new Community Group activity was structured for both purposes: to make it
> easier for the wider community to participate more fully, and to make a
> lighter-weight manner for our members to participate and build momentum for a
> topic or technology.  We consulted with our members when forging the patent
> policy. 
>

No momentum should be needed for material that actually was in a LC document already in the Rec track. This is not "new" stuff. 
 
> Why would W3C, a member organization, make a project that our members can't
> participate in? How would that be fair or inclusive?
> 
> 
> Personally, I'm very glad to see a more modular approach to incrementally
> improving HTML, rather than the single-editor monolithic approach we have now,
> and I'm grateful to Aryeh for all the work he's done on this, and for starting
> a Community Group around it.  It looks like good technical work, and that's the
> chief basis on which this effort should be judged.


And I've never said anything about Aryeh's work, only where the work resides. 

However, I believe this will eventually be addressed by the W3C leadership.

Just to ensure we're all clear on copyright and patents, following is a rather good description of the differences between the two:

"Copyright protects original works of authorship, while a patent protects inventions or discoveries. Ideas and discoveries are not protected by the copyright law, although the way in which they are expressed may be."

I'm not a lawyer, but this tells me that a free to use copyright on Aryeh's text only covers the text, not the idea. We can copy the text, but this doesn't cover implementation. 

If we implement the idea, then we're running into potential patent problems. 

This is from the US Copyright Office[1]. I imagine the same or something similar applies in other countries. 

That's why the location of the document matters.

[1] http://www.copyright.gov/help/faq/faq-general.html

Sorry, one more and then I'll shut up:

Again, not a lawyer, but...

If we fork Aryeh's work, we don't have patent protection, because Google could assert it's patent rights on the ideas expressed in Aryeh's work, if the original material resides outside of the W3C.

However, if Aryeh or someone else from Google submits the material to the W3C as a member of the W3C, then the material would be covered under the patent agreement all members sign when joining. 

If Aryeh feels he could not do so, then I'd rather leave the text in HTML5, and just file bug reports to try to fix the material. It's not the best option, but it's the safest to implementors--at least as I understand the patent risks. 

If the W3C's lawyers feel that this is not a risk, I would withdraw my objections. 

I'm not being persistent on this for fun, or to disparage Aryeh's excellent and hard work.

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.

(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/

(In reply to comment #34)
> Just to ensure we're all clear on copyright and patents, following is a rather
> good description of the differences between the two:

Shelley, we all know the difference between copyrights and patents.  


> "Copyright protects original works of authorship, while a patent protects
> inventions or discoveries. Ideas and discoveries are not protected by the
> copyright law, although the way in which they are expressed may be."
> 
> I'm not a lawyer, but this tells me that a free to use copyright on Aryeh's
> text only covers the text, not the idea. We can copy the text, but this 
> doesn't cover implementation. 
> 
> If we implement the idea, then we're running into potential patent problems. 
> 
> This is from the US Copyright Office[1]. I imagine the same or something
> similar applies in other countries. 
> 
> That's why the location of the document matters.

Yes, and that's why it's good that he's bringing it to a Community Group (assuming he follows through on joining the CG, which is his stated intent).  CGs have both a patent policy and a copyright policy:
 http://www.w3.org/community/about/agreements/cla/

But it's not enough for Aryeh alone to make patent (and copyright) commitments... since this spec is based on the technical work of others, including browser vendors like Microsoft (who started the work originally), he isn't the one who is likely to control the patents (and neither is Google)... this is why we need, at some point, to either get the key stakeholders (i.e. likely patent holders) to make patent commitments, either by joining the CG, or though bringing the Editing API spec, once it is mature, to a WG that has those stakeholders in it... probably the HTML WG.

This is not a new issue with Community Groups... getting the right stakeholders in a group is always a concern at W3C.  CGs are actually a very interesting and potentially powerful tool to make standardization faster and easier while still getting patent commitments.

I'm very happy to see Aryeh kicking the tires on this new activity: https://plus.google.com/100662365103380396132/posts/TSCsoGYSC2h

So, in relation to this bug, I don't have a strong opinion on whether the text is removed from the HTML5 spec, if the contradictions are resolved and the text in the HTML5 spec can be made a proper subset of Aryeh's spec, because then we get broader patent commitment.  If these changes can't be made, then it is probably better to remove it.

(In reply to comment #38)
> (In reply to comment #34)
> > Just to ensure we're all clear on copyright and patents, following is a rather
> > good description of the differences between the two:
> 
> Shelley, we all know the difference between copyrights and patents.  

I wasn't sure when I read the following:

"Aryeh has made it clear that his spec is under an open license, and that W3C
(or anyone else) can use it.  How could W3C have a problem with that?"

Since the "open license" only covered the text, not the ideas expressed in the text. 

However, neither here nor there...

> 
> 
> > "Copyright protects original works of authorship, while a patent protects
> > inventions or discoveries. Ideas and discoveries are not protected by the
> > copyright law, although the way in which they are expressed may be."
> > 
> > I'm not a lawyer, but this tells me that a free to use copyright on Aryeh's
> > text only covers the text, not the idea. We can copy the text, but this 
> > doesn't cover implementation. 
> > 
> > If we implement the idea, then we're running into potential patent problems. 
> > 
> > This is from the US Copyright Office[1]. I imagine the same or something
> > similar applies in other countries. 
> > 
> > That's why the location of the document matters.
> 
> Yes, and that's why it's good that he's bringing it to a Community Group
> (assuming he follows through on joining the CG, which is his stated intent). 
> CGs have both a patent policy and a copyright policy:
>  http://www.w3.org/community/about/agreements/cla/
> 
> But it's not enough for Aryeh alone to make patent (and copyright)
> commitments... since this spec is based on the technical work of others,
> including browser vendors like Microsoft (who started the work originally), he
> isn't the one who is likely to control the patents (and neither is Google)...
> this is why we need, at some point, to either get the key stakeholders (i.e.
> likely patent holders) to make patent commitments, either by joining the CG, or
> though bringing the Editing API spec, once it is mature, to a WG that has those
> stakeholders in it... probably the HTML WG.
> 
> This is not a new issue with Community Groups... getting the right stakeholders
> in a group is always a concern at W3C.  CGs are actually a very interesting and
> potentially powerful tool to make standardization faster and easier while still
> getting patent commitments.
> 
> I'm very happy to see Aryeh kicking the tires on this new activity:
> https://plus.google.com/100662365103380396132/posts/TSCsoGYSC2h
>

If the preference is to begin work on this in the CG and then eventually move it over to the REC track in the HTML WG then I'm not as concerned. It seems to me to be a little backwards, since the text is already in the HTML WG, but whatever.

As long as everyone agrees that's the goal of this move: to get all relevant parties on board on the document, and then to move it into the REC track. That the intention is _not_ to keep it indefinitely in the CG.

 
> So, in relation to this bug, I don't have a strong opinion on whether the text
> is removed from the HTML5 spec, if the contradictions are resolved and the text
> in the HTML5 spec can be made a proper subset of Aryeh's spec, because then we
> get broader patent commitment.  If these changes can't be made, then it is
> probably better to remove it.

True, we can pursue this option by filing bugs against the text in the HTML5 spec.

As usual, sidebar commenting on the WHATWG IRC

http://krijnhoetmer.nl/irc-logs/whatwg/20110819#l-535

If the W3C doesn't care about a mess getting worse than it already is, I'm not going to stand in the way. 

I'm removing my email from the cc list. I also remove any and all objections to anything the editor or Aryeh wants to do. 

I genuinely don't care anymore.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: Replaced Editing APIs section with a reference to Aryeh's spec.
Rationale: Having poor text redundant with another spec is bad.

I'm reluctantly forced to reopen this.

Aryeh Gregor had stated he'd move his document to the Editing API Community Group, but I've not seen this happen, this group isn't active, and Aryeh has not joined.

As it stands now, Google has, in effect, well, "absconded" is the only word I can think of to use, with other companies intellectual property, and the W3C seems to be doing little to prevent this action.

Since, as was noted earlier, other companies such as Microsoft have patent rights to the material that Aryeh took for his document, and these rights would supposedly be preserved if the document was managed by the W3C, I ask that this change be reverted. 

We can then proceed to file bugs against the material in order to provide any necessary corrections. This would, at least, preserve the W3C patent protection of the intellectual concepts encapsulated in the Editing API.

(In reply to comment #42)
> Aryeh Gregor had stated he'd move his document to the Editing API Community
> Group, but I've not seen this happen, this group isn't active, and Aryeh has
> not joined.

I requested to join the CG immediately after opening it.  This requires approval of T.V. Raman, the Google AC rep.  He's told me that he'll approve Google's membership in the CG as soon as he gets approval from Google legal, but that's apparently taking a while.  This is what happens any time lawyers have to be involved in anything, unfortunately.

Needless to say, I continue to work on the specification in its original location.  All work I'm doing now will become part of the CG specification when that finally does get published, so we aren't losing anything from the delay.

> Since, as was noted earlier, other companies such as Microsoft have patent
> rights to the material that Aryeh took for his document, and these rights would
> supposedly be preserved if the document was managed by the W3C,

This is a severe and material misrepresentation of the patent situation, although I'm sure it's unintentional:

1) There is no reason to believe that Microsoft or any other party holds patents relevant to HTML editing.  None have been declared to date in the HTMLWG.

2) I did not "take" anything for my document.  It was written completely from scratch.

3) Even if I had taken something from HTML5, that would not infringe anyone's patents.  Patents cover only inventions, not descriptions of inventions.  Publishing material that documents or explains a patented invention -- such as, indeed, the patent application itself -- is completely fine.

4) If someone held patents relevant to editing work, the reason to have the editing specification covered by W3C patent policy would not be to preserve that entity's patent rights.  To the contrary, coverage by the patent policy could only require that entity to give a royalty-free license to others for the patent.  The patent policy *waives* patent rights, it doesn't *preserve* them.

The only relevance that the patent policy has is that it protects organizations against patent suits by members of the relevant W3C Working Group.  This is only relevant at Recommendation stage, which is to say not for a long time yet.  Thus a few extra months or whatever it takes before the editing spec is covered by a patent policy will not create any additional patent risk for anyone, and is entirely harmless from a patent-policy perspective.

> I ask that this change be reverted.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: See comment 41
Rationale: Reinstating original resolution.  If you would like to escalate, you are aware of the procedure and free to use it.  Reopening this bug again would not be productive.

Marking CLOSED, because as the original reporter I'm satisfied with the resolution.

This really isn't a Google Legal decision. Until such time as the Editing API is under W3C control, this text should be maintained in the HTML5 document. As a member organization Google agreed to abide by the W3C's policies, including the patent policy.

It's as simple as that.

If the co-chairs agree with you that you can close this item, then I'll that this item be made into a TrackerRequest. However, since the decision was made to remove the material and pull it outside of the W3C, I believe this also fits the right circumstances for a Formal Objection, too.

Since this is a fairly serious item--one member organization taking material from the W3C, even against the express wishes of another organization (Apple)--I think perhaps a Formal Objection may be the better option.

Can someone please provide an issue title and summary for the TrackerRequest?

(In reply to comment #46)
> Can someone please provide an issue title and summary for the TrackerRequest?

Title: Revert the edit that removed the Editing API

Summary: The section of the HTML5 specification that contained the editing API was removed prematurely. The disposition of this content is still under discussion.

I'm including a link to another discussion on this issue that actually happened in the Web-Apps working group email list. 

http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1402.html

I'm adding this link so that members of the HTML WG and others interested in this topic can be aware that the discussion related to the Editing API is still happening, but elsewhere.

It would make more sense to use the HTML WG email list for this effort because a) the Editing API actually originated in the HTML5 document and is still part of the HTML5 LC document, and b) the HTML WG is actually chartered to provide an Editing API specification. 

I discovered this email via an email at the WHATWG email list that references it.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033235.html

It's unfortunate that discussion related to the Editing API has become so fragmented. Such fragmentation does not aid in the development of a solid specification.

Raised as issue 176: http://www.w3.org/html/wg/tracker/issues/176