Re: CG for Speech JavaScript API

The fact that Rick picked the wrong full name already outlines the issue.

I'm strongly in favor of using non-abbreviated names as well, which also
applies to the "SpeechReco" and "TTS" JavaScript interfaces.  While they
may be obvious for people familiar with speech recognizion, a significant
group (if not the majority) of Web Developers won't be.

Peter

On Wed, Feb 1, 2012 at 12:40, Dan Burnett <dburnett@voxeo.com> wrote:

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