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. Does that clear things up? From: Satish S [mailto:satish@google.com] Sent: Wednesday, May 23, 2012 3:26 PM 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) 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'. -- Cheers Satish
Received on Wednesday, 23 May 2012 22:35:43 UTC