Re: [Dmsp] clarifications requested in draft-engelsma-dmsp-02.txt

"Engelsma Jonathan-QA2678" <Jonathan.Engelsma@motorola.com> wrote on
12/01/2006 11:17:38 AM:

> All,
>
> We're working on another revision of the dmsp spec that we hope to
> complete in the next few days.  Here is a summary of some of the areas
> that need correction/clarification in the current version.  Please
> forward any comments you have on these or other areas
>
> While working on a C++ implementation of the client state machine, Jim
> Ferrans pointed out the following items that need attention:
>
> Item 1 -  Section 4.2.3.2 VXML Start Signal Message - currently only
> supports a dialog url.  In certain situations it may be desirable for
> the client application to be completely self contained, and not
> dependent on a network-based application server.  The VXML Start message
> should be able to include actual VoiceXML content instead of an url.
>
> Comments: There are a couple of possiblities.  1) Add a flag to the
> message that indicates whether the string in the Dialog URL field is an
> URL or VoiceXML content.  2) Leave the message as it is, and let the VUA
> infer from the value of Dialog URL itself, what it is.  For example, if
> the string begins with "<?xml" treat it as VoiceXML content, otherwise
> confirm it's a fully qualified URL.  Any preferences one way or the
> other?
>

I prefer the additional field. Much cleaner data model at the cost of one
bit in the message.

> Item 2 - Section 4.2.6.7 - 4.2.6.8. Originally, the Motorola
> implementation of the server state machine, only reported the slots
> corresponding to VoiceXML form items that have changed value during a
> given recognition cycle are reflected in the recognition result
> messages.  The motivation for this approach was to minimize message
> size.  However, application developers have argued convincingly that
> this is not helpful, and its best for the recognition result to fully
> represent what the user actually said...
>
> Comments: We should add wording in these sections to clarify this
> situation.  Any additional or contrary thoughts from other server
> implementors?
>

Interesting question. I've always read "field" in tables 7 and 8 to
referring to VoiceXML fields;-) When the VUA is a VoiceXML processor, reco
result can come from one of two situations: 1) when processing an
individual field or 2) from a form level grammar for a mixed initiative
form. In the first case, by definition the reco result should just return
the result for the field. In the second, the result should be returned for
all the fields that were filled. I believe if an implementation returns
more than the fields that were filled then it breaks the semantics of mixed
initiative which allows for partial filling of a form with a single
utterance that matches the form level grammar. This question requires a
careful reading of the VoiceXML spec. Re-reading Item 2, doesn't sending
only what changed "fully represent what the user actually said?"

> In addition to these issues Jim raised, there were a couple of other
> minor issues reported that need clarification/correction:
>
> Item 3: Table 11 - The 7th field in the table "Event Type" is actually a
> typo and will be eliminated in the next revision.
>
> Item 4: Section 4.2.4.9, Table 21.  The 5th field listed in the table
> "Fields" is meant to be an array of strings, NOT an array of Fields
> values as defined in Table 7.  Hence the reference "see Table 7" in the
> Value column in Table 21 is incorrect.  This will be updated in the next
> revision.

I concur with both corrections.

Chris