RE: Propose errata for emma attribute

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>