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