Re: Propose errata for emma attribute

Yes, here's that original proposal (with null instead of undefined).

Add: ", or if the recognizer does not supply EMMA then the user agent may
return null."

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

[1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-emma




On Wed, Jan 23, 2013 at 5:22 AM, Deborah Dahl <
dahl@conversational-technologies.com> wrote:

> I think we should leave the emma property in the spec since that will
> improve interoperability across recognizers that do and don’t support emma.
> ****
>
> I would prefer to be able to get a simple emma representation instead of
> null if the recognizer doesn’t support emma, but if that’s too difficult,
> then I think we should go ahead and allow “null” as in Glen’s original
> proposal.****
>
> ** **
>
> ** **
>
> *From:* Glen Shires [mailto:gshires@google.com]
> *Sent:* Tuesday, January 22, 2013 7:42 PM
> *To:* olli@pettay.fi
> *Cc:* public-speech-api@w3.org
> *Subject:* Re: Propose errata for emma attribute****
>
> ** **
>
> Yes, I was responding to your comment: "Could we even drop the property
> from v1?" and proposing to remove the attribute altogether (thus
> "undefined").****
>
> ** **
>
> I agree, if instead its supported in some cases and not others, then it
> should be "null" for the cases it's not supported.****
>
> ** **
>
> On Tue, Jan 22, 2013 at 4:35 PM, Olli Pettay <Olli.Pettay@helsinki.fi>
> wrote:****
>
> 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 18:02:59 UTC