- From: Glen Shires <gshires@google.com>
- Date: Thu, 16 Aug 2012 06:29:17 -0700
- To: Bjorn Bringert <bringert@google.com>
- Cc: Hans Wennborg <hwennborg@google.com>, Conversational <dahl@conversational-technologies.com>, "public-speech-api@w3.org" <public-speech-api@w3.org>
- Message-ID: <CAEE5bcgQ0DTHnNoY6duxmK+Vj-2pZXNOHYeEGaYiWM2=mj1CRw@mail.gmail.com>
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