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

Yes, the developer has control over what values are returned ... except
when they're not returned.

It's easier to check for undefined than check for type string.
I agree that it's not a big deal either way "for the typical way this would
be used", however if the developer wanted to do something else, it may be
more complex (check type for a string, check that both strings match, etc).

Seems to me that undefined is a little simpler in some cases, and a lot
simpler in other cases.

/Glen Shires

On Thu, Aug 16, 2012 at 6:24 AM, Bjorn Bringert <bringert@google.com> wrote:

> The interpretation typically comes from SISR tags that the developer
> has written. So the developer has control over what values are
> returned and when.
>
> Also, as you mention, the typical way this would be used would be to
> use "transcript" if "interpretation" is empty. Putting the text in
> "interpretation" does that for you.
>
> It's not a big deal either way though I think.
>
> On Thu, Aug 16, 2012 at 2:20 PM, Glen Shires <gshires@google.com> wrote:
> > I propose that last sentence be replaced by "If no semantic meaning can
> be
> > determined, the attribute must return 'undefined'."
> >
> > The reason being that this simplifies the developer's coding. The
> > interpretation attribute is of type "any" because it typically returns
> > structured data.
> >
> > 'undefined' allows the developer to perform a simple check to determine
> if
> > the interpretation is present, and if not, simply use the transcript
> > attribute, which is always a string.
> >
> > Conversely, the developer would have to check for the type of the
> object(s)
> > returned in the interpretation attribute, requiring significantly more
> > complex code.
> >
> > /Glen Shires
> >
> >
> > On Thu, Aug 16, 2012 at 5:58 AM, 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
>

Received on Thursday, 16 August 2012 13:30:27 UTC