I had to check with my co-worker Michael on this one...
--------
In as far as the contents of the <instance> are your semantic
interpretation to shove into the VXML variable, that is true... except
when an ASR engine is not giving you something specifically true to the
spec. As far as I am aware, Nuance is the only ASR engine that does this
using the SWI tags.

<SWI_literal> contains the literal input.

<SWI_meaning> contains whatever the semantic result is

For another example, from a nuance grammar pdf:
<instance>
   <answer>elephant</answer>
   <SWI_meaning>{answer:elephant}</SWI_meaning>
   <SWI_literal>blue elephant flies</SWI_literal>
</instance>

In this example, you can see the <answer> tag is in the instance, giving
you a nice semantic interpretation. What was spoken differs from the
semantic result, due to the use of the grammar <tag>s to alter the
semantic interpretation. The <tag>s simplified the result to
'answer="elephant";'.
The <SWI_meaning> tag contains "answer:elephant" which is a summary of the
result and points you at the <answer> property for the meaning(read:
interpretation). 

If the <SWI_meaning> tag points you at the <SWI_literal>, just use it's
contents as your result.

If <SWI_meaning> doesn't have the '{x:y}' format, it's probably just a
simple string semantic interpretation.

If your semantic interpretation is an object hierarchy, the SWI_meaning
contains the string representation of that objection. I don't recall what
this looks like, but you at least get the name of the object property to
pull from the xml structure and can build the ECMAScript object yourself.
---------------
Regards,
Chris

On 02/08/2011 01:35 PM, Luke-Jr wrote:

On Tuesday, February 08, 2011 2:09:08 pm Chris Davis wrote:

> >> Why would the MRCP server be providing a semantic interpretation of its

> >> own

>

> That's just Nuance.

>

> >>How should a conforming VoiceXML interpreter handle cases like this?

>

> use the SWI_meaning tag and pull out the value as the semantic

> interpretation.

> so.. the following:

>

> <SWI_meaning>

> {SWI_literal:1 2 3 4}

> </SWI_meaning>

>

> results in the input var being:

>

> "1 2 3 4"

So change behaviour such that (spec in black, changes in red):

A field-level result fills the associated input item in the following manner:

1. If the interpretation is a simple result, this is assigned to the input

item variable.

2. If the interpretation is a structure and the slot name matches a property,

this property's value is assigned to the input item variable.

3. If the interpretation is a structure and has a "SWI_meaning" property,

parse that property as a JSON interpretation, and go to step 1.

4. If the interpretation contains only a single "SWI_literal" property, this

property's value is assigned to the input item variable.

5. Otherwise, the full semantic result is assigned.

Correct?

Thanks,

Luke



-- 
Chris Davis
Interact Incorporated R&D
512-502-9969x117