Re: Propose errata for emma attribute

I agree that JSON syntax may be more useful than a DOM tree. Since there is
some uncertainty, I agree that dropping the attribute from the spec has
merit.

So I'd like to propose this as errata:

emma attribute
This attribute should return "undefined".
[Editor note: The group has discussed various options for the emma syntax,
including XML/DOM and JSON syntax.]


If that's not acceptable, then I'd be fine with having .emma return null in
the case where the recognizer does not supply EMMA...

emma attribute
EMMA 1.0 representation of this result. [EMMA] The contents of this result
could vary across user agents and recognition engines, but all
implementations must expose a valid XML document complete with EMMA
namespace, or if the recognizer does not supply EMMA then the user agent
may return null. User agent implementations for recognizers that supply
EMMA must contain all annotations and content generated by the recognition
resources utilized for recognition, except where infeasible due to
conflicting attributes. The user agent may add additional annotations to
provide a richer result for the developer.

If there's no disagreement, I'll update the errata on Feb 4.
Glen


On Tue, Jan 22, 2013 at 10:39 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 01/20/2013 05:32 AM, Glen Shires wrote:
>
>> We've found that generating a "simple" XML/DOM wrapper of the results for
>> the SpeechRecognitionEvent emma attribute is more challenging to implement
>> than originally thought. I propose that the UA may return undefined for
>> implementations in which the speech recognition engine does not supply emma.
>>   In this case, emma doesn't provide any additional information than is
>> already available via the API in the results attribute.
>>
>> Specifically, I propose adding the phrase: ", or if the recognizer does
>> not supply EMMA then the user agent may return undefined."
>>
>
>
> I think returning null would make more sense and be compatible with XHR.
> Though I'm not a fan of sort-of-optional features. Could we even drop the
> property from v1? But, I'm not against having .emma just returning null for
> now.
>
>
> Also, it would be nice if we had JSON syntax for EMMA. Accessing JS object
> tree would be more natural than DOM tree.
> This was discussed during XG, but don't recall if MMI WG was asked to
> think about JSON version of EMMA.
>
> -Olli
>
>
>
>> Here it is in context [1] ...
>>
>> emma attribute
>> EMMA 1.0 representation of this result. [EMMA] The contents of this
>> result could vary across user agents and recognition engines, but all
>> implementations must expose a valid XML document complete with EMMA
>> namespace, or if the recognizer does not supply EMMA then the user agent may
>> return undefined. User agent implementations for recognizers that supply
>> EMMA must contain all annotations and content generated by the recognition
>> resources utilized for recognition, except where infeasible due to
>> conflicting attributes. The user agent may add additional annotations to
>> provide a
>> richer result for the developer.
>>
>> [1] https://dvcs.w3.org/hg/speech-**api/raw-file/tip/speechapi.**
>> html#dfn-emma<https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-emma>
>>
>
>