Re: SpeechRecognitionAlternative.interpretation when interpretation can't be provided

I agree, return "null" (not "undefined") in such cases.

On Fri, Aug 17, 2012 at 7:41 AM, Satish S <satish@google.com> wrote:

> > I may have missed something, but I don’t see in the spec where it says
> that “interpretation” is optional.
>
> Developers specify the interpretation value with SISR and if they don't
> specify there is no 'default' interpretation available. In that sense it is
> optional because grammars don't mandate it. So I think this API shouldn't
> mandate providing a default value if the engine did not provide one, and
> return null in such cases.
>
> Cheers
> Satish
>
>
>
> On Fri, Aug 17, 2012 at 1:57 PM, Deborah Dahl <
> dahl@conversational-technologies.com> wrote:
>
>> I may have missed something, but I don’t see in the spec where it says
>> that “interpretation” is optional. ****
>>
>> *From:* Satish S [mailto:satish@google.com]
>> *Sent:* Thursday, August 16, 2012 7:38 PM
>> *To:* Deborah Dahl
>> *Cc:* Bjorn Bringert; Hans Wennborg; public-speech-api@w3.org
>>
>> *Subject:* Re: SpeechRecognitionAlternative.interpretation when
>> interpretation can't be provided****
>>
>> ** **
>>
>> 'interpretation' is an optional attribute because engines are not
>> required to provide an interpretation on their own (unlike 'transcript').
>> As such I think it should return null when there isn't a value to be
>> returned as that is the convention for optional attributes, not 'undefined'
>> or a copy of some other attribute.****
>>
>> ** **
>>
>> If an engine chooses to return the same value for 'transcript' and
>> 'interpretation' or do textnorm of the value and return in 'interpretation'
>> that will be an implementation detail of the engine. But in the absence of
>> any such value for 'interpretation' from the engine I think the UA should
>> return null.****
>>
>>
>> Cheers
>> Satish
>>
>> ****
>>
>> On Thu, Aug 16, 2012 at 2:52 PM, Deborah Dahl <
>> dahl@conversational-technologies.com> wrote:****
>>
>> That's a good point. There are lots of use cases where some simple
>> normalization is extremely useful, as in your example, or collapsing all
>> the ways that the user might say "yes" or "no". However, you could say that
>> once the implementation has modified or normalized the transcript that
>> means it has some kind of interpretation, so putting a normalized value in
>> the interpretation slot should be fine. Nothing says that the
>> "interpretation" has to be a particularly fine-grained interpretation, or
>> one with a lot of structure.****
>>
>>
>>
>> > -----Original Message-----
>> > From: Bjorn Bringert [mailto:bringert@google.com]
>> > Sent: Thursday, August 16, 2012 9:09 AM
>> > To: Hans Wennborg
>> > Cc: Conversational; public-speech-api@w3.org
>> > Subject: Re: SpeechRecognitionAlternative.interpretation when
>> > interpretation can't be provided
>> >
>> > I'm not sure that it has to be that strict in requiring that the value
>> > is the same as the "transcript" attribute. For example, an engine
>> > might return the words recognized in "transcript" and apply some extra
>> > textnorm to the text that it returns in "interpretation", e.g.
>> > converting digit words to digits ("three" -> "3"). Not sure if that's
>> > useful though.
>> >
>> > On Thu, Aug 16, 2012 at 1:58 PM, Hans Wennborg
>> > <hwennborg@google.com> wrote:
>> > > Yes, the raw text is in the 'transcript' attribute.
>> > >
>> > > The description of 'interpretation' is currently: "The interpretation
>> > > represents the semantic meaning from what the user said. This might be
>> > > determined, for instance, through the SISR specification of semantics
>> > > in a grammar."
>> > >
>> > > I propose that we change it to "The interpretation represents the
>> > > semantic meaning from what the user said. This might be determined,
>> > > for instance, through the SISR specification of semantics in a
>> > > grammar. If no semantic meaning can be determined, the attribute must
>> > > be a string with the same value as the 'transcript' attribute."
>> > >
>> > > Does that sound good to everyone? If there are no objections, I'll
>> > > make the change to the draft next week.
>> > >
>> > > Thanks,
>> > > Hans
>> > >
>> > > On Wed, Aug 15, 2012 at 5:29 PM, Conversational
>> > > <dahl@conversational-technologies.com> wrote:
>> > >> I can't check the spec right now, but I assume there's already an
>> attribute
>> > that currently is defined to contain the raw text. So I think we could
>> say that
>> > if there's no interpretation the value of the interpretation attribute
>> would be
>> > the same as the value of the "raw string" attribute,
>> > >>
>> > >> Sent from my iPhone
>> > >>
>> > >> On Aug 15, 2012, at 9:57 AM, Hans Wennborg <hwennborg@google.com>
>> > wrote:
>> > >>
>> > >>> OK, that would work I suppose.
>> > >>>
>> > >>> What would the spec text look like? Something like "[...] If no
>> > >>> semantic meaning can be determined, the attribute will a string
>> > >>> representing the raw words that the user spoke."?
>> > >>>
>> > >>> On Wed, Aug 15, 2012 at 2:24 PM, Bjorn Bringert
>> > <bringert@google.com> wrote:
>> > >>>> Yeah, that would be my preference too.
>> > >>>>
>> > >>>> On Wed, Aug 15, 2012 at 2:19 PM, Conversational
>> > >>>> <dahl@conversational-technologies.com> wrote:
>> > >>>>> If there isn't an interpretation I think it would make the most
>> sense
>> > for the attribute to contain the literal string result. I believe this
>> is what
>> > happens in VoiceXML.
>> > >>>>>
>> > >>>>>> My question is: for implementations that cannot provide an
>> > >>>>>> interpretation, what should the attribute's value be? null?
>> > undefined?
>> >
>> >
>> >
>> > --
>> > Bjorn Bringert
>> > Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
>> > Palace Road, London, SW1W 9TQ
>> > Registered in England Number: 3977902
>>
>>
>> ****
>>
>> ** **
>>
>
>