Re: CG for Speech JavaScript API

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

Re: WebSocket API clise Method

On 1.2.2012 5:43, Takashi Toyoshima wrote:
> Hi Bronislav,
>
> On Tue, Jan 31, 2012 at 11:09 PM, Bronislav Klučka
> <Bronislav.Klucka <at> bauglir.com>  wrote:
>> Hello,
>> based on this bug
>> http://code.google.com/p/chromium/issues/detail?id=93609
>> referencing
>> http://dev.w3.org/html5/websockets/#dom-websocket-close
>>
>> Looking in WebSocket protocol close codes definitions
>> http://tools.ietf.org/html/rfc6455#section-7.4.1
>>
>> I wonder about codes
>>
>> 1003 indicates that an endpoint is terminating the connection
>>       because it has received a type of data it cannot accept (e.g., an
>>       endpoint that understands only text data MAY send this if it
>>       receives a binary message).
>>
>> 1008 indicates that an endpoint is terminating the connection
>>       because it has received a message that violates its policy.  This
>>       is a generic status code that can be returned when there is no
>>       other more suitable status code (e.g., 1003 or 1009) or if there
>>       is a need to hide specific details about the policy.
>>
>> 1009 indicates that an endpoint is terminating the connection
>>       because it has received a message that is too big for it to

Re: CG for Speech JavaScript API

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 <at> 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,

Re: CG for Speech JavaScript API

Re: RfC: LCWD of Web Socket API; comment deadline October 21

On 2012-01-03 13:39, Arthur Barstow wrote:
> On 12/29/11 8:48 AM, ext Julian Reschke wrote:
>> I note that
>> <http://www.w3.org/2008/webapps/wiki/Websockets-Comments-LC-29Sep2011>
>> claims this was addressed but it was not.
>>
>> (In the meantime the reference additionally is out-of-date as RFC 6455
>> has been published a few days later, and not waiting with publishing
>> the CR is a sort-of embarasssing #FAIL of W3C/IETF coordination).
>
> The above is captured in bug 15400.

But apparently hard to fix.

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

Re: CG for Speech JavaScript API

[Bug 15829] New: wrong bug tracker ref

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15829

           Summary: wrong bug tracker ref
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian <at> hixie.ch
        ReportedBy: julian.reschke <at> gmx.de
         QAContact: member-webapi-cvs <at> w3.org
                CC: mike <at> w3.org, public-webapps <at> w3.org

"our public bug database" links to

  http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG

(wrong WG)

--

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 15830] New: incorrect protocol spec ref

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15830

           Summary: incorrect protocol spec ref
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
        AssignedTo: ian <at> hixie.ch
        ReportedBy: julian.reschke <at> gmx.de
         QAContact: member-webapi-cvs <at> w3.org
                CC: mike <at> w3.org, public-webapps <at> w3.org

"WebSocket Protocol Internet-Draft:
http://www.whatwg.org/specs/web-socket-protocol/"

Why is this linking to a draft that has been obsolete for over 17 months?

--

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 15830] incorrect protocol spec ref

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15830

Julian Reschke <julian.reschke <at> gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Julian Reschke <julian.reschke <at> gmx.de> 2012-02-01 13:24:23 UTC ---

*** This bug has been marked as a duplicate of bug 13700 ***

--

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.