RE: VoiceXML comments from Elvira development team - part I

I can answer a few of these questions.  I'm assuming that your citations are
to the latest public working draft, dated 10.23.2001.

> 2 - ECMA Script variables must be declared
> <cite chapter="5.3.12">
>     All variables must be declared before being referenced by 
>     ECMAScript scripts, or by VoiceXML elements.
> </cite>
> Can be use of undeclared variables in ECMA Script prevented somehow?

Certainly.  The VoiceXML 2.0 drafts don't specify *how* you prevent this,
just that you *must* prevent it.  If you're using one of the open-source
JavaScript interpreters like Rhino, it's not that hard to do.  Just create
your own global scope object and have it throw an error when someone tries
to create a variable in it.

> 3 - Catch selection algorithm
> Is it true that the catch element selection algorithm gives 
> priority to catch elements that occur earlier in a document?

Yes.  This behavior is the same as in VoiceXML 1.0.

>4 - Grammars in <initial>
>We think it would be useful to allow grammars in <initial>. The grammars
would
>be active only during executing <initial>.

I personally agree, though it's not a strong opinion either way.  This has
been discussed before, and I think someone proposed a change request for
this.  I don't remember why it didn't make it in.

>5 - External events
These seem beyond the scope of VoiceXML 2.0 to me, so I won't address them.

>6 - Telephony
>If VoiceXML is considered to be a _general_ language for description of the
>dialog flow rather then tailored for telephony, then also PC keyboard (or
>better a keyboard in general) should be supported as input device

This has been a goal all along, so VoiceXML is accessible to the hearing
impaired.  The W3C grammar formats aren't really limited to "voice" and
"dtmf", though that's what the modes are called.  As an existence proof,
check out the "Vocal Scripter" tool on our site, cafe.bevocal.com.  I think
other vendors have done the same thing.  

>7 - FIA description and scopes
>It results in the same behavior because in the "standard" FIA, events are
>processed in the beginning of the process phase. "Our" process phase begins
>before the scope is closed, thus it is simple to find appropriate event
>handlers in the scope of the field item.

I agree that your description is more clear -- it makes more sense to enter
the form item's scope and stay there until you're done processing the result
and/or event.  And if it produces the same behavior as the standard FIA,
then you're still compliant.

I think you would find a lot of resistance to changing the wording in the
VoiceXML 2.0 drafts at this point.  The FIA section has had a lot of time to
stabilize, and people would be afraid of introducing bugs if they made any
major changes to it.

> 8 - order of <filled> calls
> ---------------------------
> <cite chapter="2.4">
>    After each gathering of the user's input, all the fields mentioned in
the
>    input are set, and then the interpreter looks at each <filled> element
in
>    document order (no preference is given to ones in fields vs. ones in
the
>    form).
> </cite>
> 
> Why there is a change of preferences in VoiceXML 2.0 against 1.0?

There isn't.  VoiceXML 1.0 has the same exact wording you cite.

> 9 - Grammars with document scope
> ---------------------------------
> It is only a speculation, but wouldn't be more inteligible to 
> have document
> scoped grammars physically placed under <vxml> element and 
> the grammars would
> have an attribute with id of the form which should be entered 
> when the grammar
> is matched?

I'd rather have them in the form where their slots are going to be used to
fill fields, so I can see at a glance which fields will be filled with which
slots.  But I can see the arguments either way.


Laura Werner
BeVocal, Inc.

Received on Friday, 19 April 2002 15:06:04 UTC