W3C home > Mailing lists > Public > public-speech-api@w3.org > May 2012

Re: EMMA in Speech API (was RE: Speech API: first editor's draft posted)

From: Satish S <satish@google.com>
Date: Wed, 30 May 2012 16:19:13 +0100
Message-ID: <CAHZf7Rm4Qu1Wm6nD7EfQjEMRf-L8RHkdd0MPyQNeGDRwS5sQVw@mail.gmail.com>
To: "Young, Milan" <Milan.Young@nuance.com>
Cc: Bjorn Bringert <bringert@google.com>, Deborah Dahl <dahl@conversational-technologies.com>, Glen Shires <gshires@google.com>, Hans Wennborg <hwennborg@google.com>, "public-speech-api@w3.org" <public-speech-api@w3.org>
>
> Satish, please take a look at the use cases below.  Items #1 and #3 cannot
> be achieved unless EMMA is always present.
>

To clarify, are you suggesting that speech recognizers must always return
EMMA to the UA, or are you suggesting if they don't the UA should create a
wrapper EMMA object with just the utterance(s) and give that to the web
page? If it is the latter then #1 and #3 can't be achieved anyway because
the UA doesn't have enough information to create an EMMA wrapper with all
possible data that the web app may want (specifically it wouldn't know
about what to put in the emma:process and emma:fields given in those use
cases). And if it is the former that seems out of scope of this CG.

I'd like to add another use case #4.  Application needs to post the
> recognition result to server before proceeding in the dialog.  The server
> might be a traditional application server or it could be the controller in
> an MMI architecture.  EMMA is a standard serialized representation.
>

If the server supports EMMA then my proposal should work because the web
app would be receiving the EMMA Document as is.

--
Cheers
Satish
Received on Wednesday, 30 May 2012 15:19:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 May 2012 15:19:45 GMT