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, 23 May 2012 23:25:40 +0100
Message-ID: <CAHZf7RnJCbXOtFCC-vkXL90gUnd-G88uYBXFR30p2V9RT-Z=wA@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>
> I fail to understand your motivation for allowing null on emma:

My previous post mentioned the motivation:
"The reasoning is that accessing the raw utterance value is far simpler
with the JS object (alternative.utterance) than navigating through the emma
xml DOM, so the emma attribute will be useful only for those web apps which
require additional data from the recognizer and know that the service they
are using will be sending that data."

I am not in favour of duplicating the same data in multiple fields. So
unless the recognizer gives EMMA data with the results I don't see the
value in creating an EMMA wrapper around the utterance.

  - If the issue is efficiency, the request can be late bound.  That is the
> browser can avoid producing the EMMA object until such time as it is
> requested.****
>   - If the issue is time to implementation, we’re going to need to
> escalate this conversation.  Debbie and I demonstrated a simple wrapper
> that can be implemented with a few lines of code.  Avoiding a few lines of
> browser code is not sufficient motivation for breaking compatibility across
> implementations.

This isn't about implementation details, I'm just trying to help make a
well designed API. It would be useful if we don't think of additions to the
API as 'just a few lines of code'.

Received on Wednesday, 23 May 2012 22:26:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:26 UTC