Re: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization

On Wed, 11 Jan 2012 22:36:28 +1100, Michael[tm] Smith <mike@w3.org> wrote:

> Satish S <satish@google.com>, 2012-01-11 10:04 +0000:
>
>> The Community Groups [1] page says they are for "anyone to socialize  
>> their
>> ideas for the Web at the W3C for possible future standardization".
>
> I don't think that page adequately describes the potential value of the
> Community Group option. A CG can be used for much more than just
> socializing ideas for some hope of standardization someday.
>
>> The HTML Speech Incubator Group has done a considerable amount of work  
>> and the final report [2] is quite detailed with requirements, use cases
>> and AP proposals. Since we are interested in transitioning to the
>> standards track now, working with the relevant WGs seems more
>> appropriate than forming a new Community Group.
>
> I can understand you seeing it that way, but I hope you can also  
> understand me saying that I'm not at all sure it's more appropriate for
> this work.

And I hope you all understand me saying that I think it is indeed more  
appropriate to move it to a formal working group, for reasons explained  
below...

> I think everybody could agree that the point is not just to produce a  
> spec that is nominally on the W3C standards track. Having something on
> the W3C standards track doesn't necessarily do anything magical to ensure
> that anybody actually implements it.

Indeed. But the same goes for a community group. Implementation commitment  
doesn't come from people writing a spec.

> I think we all want is to for Web-platform technologies to actually get
> implemented across multiple browsers, interoperably -- preferably sooner
> rather than later. Starting from the WG option is not absolutely always  
> the best way to cause that to happen. It is almost certainly not the best
> way to ensure it will get done more quickly.

Actually, I don't think that what kind of group the work happens in is  
relevant one way or another to how fast it gets implemented - and not very  
relevant to the rate of developing the spec.

> You can start up a CG and have the work formally going on within that CG  
> in a matter of days, literally. In contrast, getting it going formally as
> a deliverable within a WG requires a matter of months.

In the general case this is true. But *starting* work is easy - as Mike  
said above the goal is to get stuff interoperably implemented, in other  
words, *finished*. And the startup time only has an impact on the finish  
time in very trivial cases.

> Among the things that are valuable about formal deliverables in WGs is  
> that they get you RF commitments from participants in the WG. But one
> thing that I think not everybody understands about CGs is that they also
> get you RF commitments from participants in the CG; everybody in the CG
> has to agree to the terms of the W3C Community Contributor License
> Agreement -
>
>   http://www.w3.org/community/about/agreements/cla/
>
> Excerpt: "I agree to license my Essential Claims under the W3C CLA RF
> Licensing Requirements. This requirement includes Essential Claims that  
> I own"

There are important differences in what WGs and CGs offer, and each has  
both advantages and disadvantages in terms of the overall level of  
protection offered. A fair criticism of the process applied to HTML5 is  
that the editor claims to accept input from the working group, plus the  
WHAT-WG (whose participants have made no commitment on patents at all)  
plus anything he reads in email, blogs, the side of milk cartons, etc.  
There is a theoretical risk that he will read something placed in front of  
him by someone who has avoided joining the WG (and therefore makes no  
patent commitment) and introduce it into the spec not knowing it carries a  
patent liability. I think that in practice this is unlikely to be a real  
problem for HTML - but that doesn't mean it is unlikely to be a real  
problem for any Web technology. In particular, I think that the work being  
proposed here would benefit from being in a real working group - either  
the Voice WG or the Web Apps WG seem like sensible candidate groups, a  
priori. Web Apps has the benefit that we are in the middle of the  
rechartering process, so adding deliverables is as painless now as it can  
ever be (and the truth is that this doesn't mean trivial - broad patent  
licensing doesn't always come without some effort, which is why it is  
considered valuable).

> Anyway, despite what it may seem like from what I've said above, I'm not
> trying to do a hard sell here. It's up to you all what you choose to do.
> But I would like to help make sure you're making a fully informed  
> decision based on what the actual benefits and costs of the different
> options are.

Indeed.

cheers

Chaals

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Wednesday, 11 January 2012 14:00:48 UTC