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

I think we should avoid sending back nulls because then any developer who's
interested in the EMMA result will have to check for the null case, or check
which UA the application is running in (if using the UA native speech
recognition).  Then if they do want the EMMA, they'll have to manually
construct it if the EMMA result is null.

 

From: Satish S [mailto:satish@google.com] 
Sent: Wednesday, May 30, 2012 10:34 AM
To: Young, Milan
Cc: Bjorn Bringert; Deborah Dahl; Glen Shires; Hans Wennborg;
public-speech-api@w3.org
Subject: Re: EMMA in Speech API (was RE: Speech API: first editor's draft
posted)

 

EMMA isn't just about additional data from the recognizer.  It's a
serialized form of the recognition that's useful for everything from
compatibility with an MMI architecture to logging.  Deborah gave a few use
cases and I could probably add others.

 

So while we agree that JS properties are more useful to the code that runs
inside the browser, we have to understand that isn't the whole story.

 

Perhaps there is a misunderstanding. My proposal is that if EMMA data was
sent by the recognizer (not just additional data but all encompassing as you
mention) then it makes sense to pass it on to the web page in a DOM document
form (emmaXML or just emma). If however the recognizer did not send back
EMMA data then the UA can leave that field null.

 

This satisfies the use cases that have been brought up so far and any future
use case which will need EMMA, because I'm not advocating stripping out data
from the received EMMA xml.

 

Why is this a point of concern?