Re: Propose errata for emma attribute

I've updated the errata with the above change:
https://dvcs.w3.org/hg/speech-api/rev/fbf1109b95e3

As always, the current errata is at:
http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi-errata.html

/Glen Shires


On Wed, Jan 23, 2013 at 10:01 AM, Glen Shires <gshires@google.com> wrote:

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