Re: Propose errata for emma attribute

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)



> [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:34:22 UTC