Re: CG for Speech JavaScript API

To clarify, <reco> is short for <recognize>, not <record>.  This is, in fact, an extremely common abbreviation for anyone who uses speech recognition APIs today because it takes so long both to say and type "recognition" after the 10,000th time.

Nevertheless, a Working Group standardizing this could choose something other than <reco> for the name.

-- dan

On Feb 1, 2012, at 12:11 AM, Rick Waldron wrote:

> Just wondering why, in 2012, there are proposals for elements with abbreviated names. Please stop doing that.
> 
> <record> 
> 
> Is two characters longer and infinitely more intuitive. Say no to mistakes like <img>
> 
> Rick
> 
> On Jan 31, 2012, at 11:51 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> 
>> * Glen Shires wrote:
>>> We at Google propose the formation of a new Community Group to pursue a
>>> JavaScript Speech API. Specifically, we are proposing this Javascript API
>>> [1], which enables web developers to incorporate speech recognition and
>>> synthesis into their web pages, and supports the majority of use-cases in
>>> the Speech Incubator Group's Final Report [2]. This API enables developers
>>> to use scripting to generate text-to-speech output and to use speech
>>> recognition as an input for forms, continuous dictation and control. For
>>> this first specification, we believe this simplified subset API will
>>> accelerate implementation, interoperability testing, standardization and
>>> ultimately developer adoption.
>> 
>> Looking at "HTML Speech Incubator Group Final Report", there is a propo-
>> sal for a <reco> element. Let's say the Community Group adopts this idea
>> and several browser vendors implement it. Is the assumption that Mozilla
>> would implement a <mozReco> element while Microsoft would implement some
>> <msReco> element if they choose to adopt this, or would they agree on a
>> <experimentalReco> element? Or would they implement a <reco> element? If
>> they implement plain <reco>, there is not much room for a Working Group,
>> where this might be standardized in the future, to make major changes,
>> meaning they would be mostly rubber-stamping the Community Group output.
>> -- 
>> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
>> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
>> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
>> 
>

Received on Wednesday, 1 February 2012 12:40:46 UTC