Re: Propose errata for emma attribute

On 01/23/2013 02:33 AM, Olli Pettay wrote:
> On 01/23/2013 01:42 AM, Glen Shires wrote:
>> 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".
> null
> (I don't understand why it would return undefined)
>
>

Unless you actually mean the property isn't there at all if EMMA isn't supported?


>
>> [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 <mailto: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>
>>
>>
>>
>

Received on Wednesday, 23 January 2013 00:35:55 UTC