RE: VoiceXML 2.0: Official Response #1 to Candidate Recommendation Issues

Scott,

Thanks to you and to the VBWG for your response to my comments. I am
satisfied with the VBWG's resolutions except for the following points which
follow.

I take opportunity of your response to also ask status about the following
comments I made concerning the Implementation Report TestSuite, especially
as the VXML forum is now planning on using this suite as a basic for its
conformance program. Can the VBWG communicate target dates for the next
updated version of the IR Test Suite and the VXML specifications?

http://lists.w3.org/Archives/Public/www-voice/2003JulSep/0067.html
http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0100.html

Thanks and best regards,

Guillaume.

--------------------------------------------------------------------
Eloquant offers VXML hosting and trainings in France and in Europe,
come learn more at www.eloquant.com

Guillaume Berche
Eloquant, ZA Le malvaisin
38240 Le Versoud, France
guillaume.berche@eloquant.com
--------------------------------------------------------------------

> Issue CR5-7
> 6- Precise the semantics of the dtmf attribute of option elements
>
> Suggested modification to section "2.3.1.3. Fields Using Option Lists":
>
> "dtmf    An **optional** DTMF sequence for this option. It is equivalent
> to
> a simple DTMF <grammar> and DTMF properties (Section 6.3.3) apply to
> recognition of the sequence. Unlike DTMF grammars, whitespace is
> optional:
> dtmf="123#" is equivalent to dtmf="1 2 3 #". **If unspecified, no DTMF
> grammar is associated to this option, meaning that this option can not
> be
> matched using a DTMF**"
>
> Rationale: it would make sense to add an option similar to the menu's
> dtmf
> attribute so that dtmf sequence is automatically generated. Without this
> attribute, how would an VXML author prevent the automatic generation of
> DTMF
> grammars that may override other grammars (such as links)?
> In addition, we would also need to specify what happens if a specified
> option's dtmf attributes overlaps an automatically assigned dtmf. Should
> this throw an "error.semantic" event as for choice elements or should we
> rather apply the default grammar precedence algorithm to select the
> matching
> element?
>
> CR5-7 Resolution: accepted with modifications
>
> We accept the suggested modification to 2.3.1.3 concerning the
> description of the dtmf attribute. We reject the rationale that option
> should allow automatically generated dtmf sequences.

I am satisfied with this resolution, can you please however detail the
reasons behind rejection that "option should allow automatically generated
dtmf sequences"?




> Issue CR5-8
> 7- Precise semantics of Clear element.
>
> Section "5.3.3 CLEAR" states that "The <clear> element resets one or
> more
> form items" However, the definition of the namelist attribute adds that
> "this [i.e. the namelist] can include variable names other than form
> items"
> Besides, in the case where the namelist includes variable names other
> than
> form items, what is the variable scope in which the variable must be
> defined
> to be cleared?
>
> Since a Clear element is an executable which may be included in a catch
> element, which variable scope does it targets? In other words, would the
> reset of a non-form item variable target the anonymous, dialog, document
> or
> application-level scope?
> [In addition, the Clear element may be invoked outside of the FIA (such
> as
> during the document initialization), in which the notion of active
> element
> is not clear, so relying on the scope of the active element as the scope
> in
> which a variable should be cleared is ambiguous.]
>
> Suggested text modification to Section "5.3.3 CLEAR":
> "The <clear> element resets one or more form items, and possibly other
> variables which are not form items. For each specified variable name,
> the
> variable is resolved in the closest enclosing scope of the currently
> active
> element as described in section "5.1.3 Referencing Variables". To remove
> ambiguity, each variable name in the namelist may be prefixed with a
> scope
> name as described in section "5.1.3 Referencing Variables".
>
> Once a declared variable has been identified as declared in a given
> scope S,
> its value is assigned the ECMAScript undefined value. In addition, if
> the
> variable name corresponds to a form item in scope S, then the form
> item's
> prompt counter and event counters are reset."
>
> CR5-8 Resolution: accepted with modifications
>
> We accept that the clear element should be clarified as your text
> suggests. However, we will modify the wording so that (a) variable
> references are resolved relative to the current scope, and (b) in the
> case of initialization, variable references are handled the same as for
> other ECMAScript variables.

Can you please precise what you mean by "current scope". Is the suggested
behavior of conformant VXML browsers is accepted, and are the modifications
are just wording changes?



> Issue CR5-10
> 9- Precise that the assign's name attribute does support scope prefixes
>
> The scope in which a variable is resolved is currently not clear. The
> accepted scope prefix in the name attribute is also not clear.
>
> Suggested text modification to section "5.3.2 ASSIGN"
>
> "name The name of the variable being assigned to. As specified in
> section
> "5.1.2 Variable Scopes", the corresponding variable should have been
> previously declared otherwise an error.semantic event is thrown. By
> default,
> the scope in which the variable is resolved is the closest enclosing
> scope
> of the currently active element. To remove ambiguity, the variable name
> may
> be prefixed with a scope name as described in section "5.1.3 Referencing
> Variables". Note however that the name must refer to a variable and can
> not
> refer to a property of an ECMAScript object or can not be a complex
> ECMAScript
> expression."
>
> CR5-10 Resolution: accepted with modifications
>
> We accept the suggested text modification but not the final line
> beginning "Note however".

Can you please confirm my understanding of the VBWG response on the final
line issue:
- the VBWG agrees that "name of the variable" should refer to a variable
identifier in a VXML variable scope, and not a property of an ECMAScript
object nor a complex ECMAScript function returning an ECMAScript
"Indentifier" as defined by ECMAScript specifications and refered to in
sections such as "12.12 Labelled Statements".
- However, the VBWG rejects the suggested modification which precise this
point.




> Issue CR5-13
> 12- Precise the semantics of the timeout property for the record element
>
> The specs currently state the following "A timeout interval is defined
> to
> begin immediately after prompt playback (including the 'beep' tone if
> defined) and its duration is determined by the 'timeout' property. If
> the
> timeout interval is exceeded before recording begins, then a <noinput>
> event
> is thrown. "
>
> However, how the "recording begins" is not clearly defined. I would
> assume
> that when the platform supports speech recognition during recording, the
> recording begins as soon as speech is provided by the remote end.
> However
> the specification is not clear on whether in this case the platform
> should
> remove the silence from the end of the first beep prompt up to the first
> recognised speech. It is not clear either whether background noise or
> music
> should trigger beginning of recording. For platforms not supporting
> speech
> recognition during recording I believe this timeout property should be
> ignored.
>
> Suggested text modification to section "2.3.6. RECORD":
>
> "A timeout interval is defined to begin immediately after prompt
> playback
> (including the 'beep' tone if defined) and its duration is determined by
> the
> 'timeout' property. If the timeout interval is exceeded before recording
> begins, then a <noinput> event is thrown. When the platform supports
> detection of silence, the recording begins as soon as leading silence
> (following the 'beep' tone if defined) completes. Note that whether the
> recording would include the leading silence is platform specific. For
> platforms not supporting silence detection, this property is ignored and
> no
> <noinput> event is ever raised during a recording."
>
> CR5-13 Resolution: rejected
>
> The comments no longer applies since, following analysis of
> implementation reports, the specification will no longer allow speech
> recognition during recording (no supporting implementations).
>

If the "speech recognition during recording" feature is made optional in the
VXML specifications, then I am requesting that this comment be considered
for inclusion in the 2.0 version of the specifications. If the feature is
completely removed from the specification, then I am satisfied with the
VBWG's resolutions.





> Issue CR5-16
> 15- Inconsistent behavior of option vs choice.
>
> - Choice can have nested grammars that override the default grammar
> whereas
> options can not
> - Choice can have nested audio as alternate prompts whereas options can
> not
> - Menus can have a dtfm boolean flag to turn on automatic dtmf grammar
> generation where as options within fields can not.
>
> Suggested modification: upgrade options so that they are equivalent to
> choice and only differ in the treatment of a match (which in the case of
> options does not trigger a transition)
>
> CR5-16 Resolution: rejected
>
> We see no value in making them consistent.

I don't agree with the VBWG's resolutions, but I don't wish to register an
objection to this point. Since <option> and <choice> elements are syntaxic
convenience that provide similar feature, I see great value in having them
being consistent and uniform:
Consistency usually favors understandeability of the language, and the
productivity by its users. I however understand that it may be too late to
include such consistency modification into the 2.0 version at this stage. I
therefore wish that such uniformization modifications be considered for the
next VXML version.



> Issue CR6-1
> 1- Precise that buffered non-matching DTMF are discarded when an ASR
> grammar
> matches.
>
> It is unclear in the specifications whether the following document
>
> <form name="form1">
>   <field>
>      <grammar src="builtin:grammar/boolean"/>
>      <grammar src="builtin:dtmf/digits?length=4"/>
>   <field>
>   <filled>
>      <goto next="#form2">
>   </filled>
> </form>
>
> <form name="form2">
>   <field>
>      <grammar src="builtin:dtmf/digits?length=1"/>
>   <field>
>   <filled>
>      <prompt>thanks for the dtmf</prompt>
>   </filled>
>   <noinput>
>      <prompt>DTMF was discarded</prompt>
>   </noinput>
> </form>
>
> By pressing the 1 key and speaking "yes" and waiting for the input
> timeout.
> Should the interpreter play the "thanks for the dtmf" prompt or the
> "DTMF
> was discarded" prompt?
>
> Suggested solution: specify that partially buffered data are flushed in
> case
> of grammar match in another mode.
>
> CR6-1 Resolution: rejected
>
> This is a platform-specific issue and is outside the scope of the
> specification.

I am not satisfied with the VBWG response on this point. Not being able to
understand the expected behavior of a valid VXML page from the VXML
specification appears to me as an important specifications problem and can
not be considered "outside the scope of the specification". I understand
that the VBWG might be reluctant to specify the expected behavior of a
conformant VXML browser in this specific case at this point of the
specifications process, but at least the specifications should clearly state
this position. Therefore, I register an objection to this point, and request
that a section specifying the platform specific behavior gets added.



> Issue CR6-2
>
> 2a- Rationale for not accepting local ruleref in inline SRGS grammars?
>
> Can you please provide rationale for not accepting ruleref elements with
> pure fragment URLs? Why would this be rejected in grammars provided
> inline
> in VXML documents? What is the reason driving this restriction and
> forcing
> to use remote grammars for any grammar using private rules?
>
> CR6-2 Resolution: accepted
>
> One such reason is that some interpreters will not have processed the
> inline SRGS grammars that aren't involved with the current recognition
> cycle. For instance imagine:
> <vxml version="2.0">
>   <form>
>     <field name="a">
>       <!-- inline foo grammar -->
>       <grammar>
>         <!-- inline ref to grammar bar -->
>       </grammar>
>     </field>
>   </form>
>   <form>
>     <field name="a">
>       <!-- inline bar grammar -->
>       <grammar>
>         ...
>       </grammar>
>     </field>
>   </form>
> </vxml>
>
> Another concern is that it isn't currently possible to name grammar
> tags, and as such there isn't a consistent way to reference another
> inline grammar in the file (as evidenced by the inline comment naming
> scheme). Another concern is that we wish to make resource requests of
> grammar in this way similar to script tags. It isn't possible today to
> have an inline script tag local to one form but then have a later form
> use an inline fragment to include the inline script. For all of these
> concerns we've decided to not accept local rulerefs in inline SRGS
> grammars. No changes will be made to the specification.
>

I worry there is a misunderstanding on this point. My remark mainly
concerned an inline (or remote grammar) grammar that would reference one its
private rule as show in the example below, and not a rule into another
inline (or remote) grammar.

<vxml version="2.0">
	 <form>
		 <field name="a">
			 <grammar root="request">
				 <rule id="request" scope="public">
					 <example> may I speak with Andre Roy </example>
					 <example> may I speak with Jose </example>

					 may I speak with
					 <one-of>
						 <item> <ruleref uri="#people1"/> </item>
						 <item> <ruleref uri="#people2"/> </item>
					 </one-of>
				 </rule>

				 <!-- Single language attachment to an expansion -->
				 <rule id="people1">
					 <one-of xml:lang="fr-CA">
						 <item>Michel Tremblay</item>
						 <item>Andre Roy</item>
					 </one-of>
				 </rule>
			 </grammar>
		 </field>
	 </form>
 </vxml>

Can the VBWG please describe the problems implied by changing the VXML
specification sentence from:
"Local rule reference: a fragment-only URI is not permited. (See definition
in Section 2.2.1 of [SRGS]). A fragment-only URI value for the src attribute
causes an error.semantic event"

to

"Local rule reference: a fragment-only URI is permited to refer to rules
defined within the grammar itself. This may include a remote grammar or an
inline grammar. (See definition in Section 2.2.1 of [SRGS]). An invalid
fragment-only URI value for the src attribute (i.e. not refering to any rule
defined in the same grammar) causes an error.semantic event"



> Issue CR6-9
>
> 8- Precise behavior of submit if undeclared/unvalid variables are
> references
> in submit's namelist attributes
>
> The specifications section "5.3.8 SUBMIT" states the following
>
> "The list of variables to submit. By default, all the named input item
> variables are submitted. If a namelist is supplied, it may contain
> individual variable references which are submitted with the same
> qualification used in the namelist. Declared VoiceXML and ECMAScript
> variables can be referenced."
>
> It does not specify the expected behavior in case an undeclared variable
> or
> an invalid variable name is referenced in the namelist attribute.
>
> Suggested modification to section "5.3.8 SUBMIT":
> "namelist          The list of variables to submit. By default, all the
> named input item variables are submitted. If a namelist is supplied, it
> may
> contain individual variable references which are submitted with the same
> qualification used in the namelist. Declared VoiceXML and ECMAScript
> variables can be referenced. **If an undeclared or invalid variable name
> is
> referenced then an "error.semantic" event is thrown**"
>
> CR6-9 Resolution: accepted with modifications
>
> We will modify the specification to clarify that an error.semantic is
> thrown when an undeclared variable is referenced, including reference
> within the namelist of a submit element.
>

I am satisfied with the VBWG. I however request that the same modification
be also brought to undeclared variables within the namelist attribute of the
<exit>, <return>, and <subdialog> elements in addition to the <submit>
element.



>
> Issue CR6-10
> 9- Inconsistent variable scope description:
>
> In section "5.1.2 Variable Scopes", the dialog variable scope is defined
> as:
>
> "dialog     Each dialog (<form> or <menu>) has a dialog scope that
> exists
> while the user is visiting that dialog, and which is visible to the
> elements
> of that dialog. Dialog variables are declared by <var> and <script>
> child
> elements of <form> and by the various form item elements.  "
>
> However, a block element is also a form item, as such variables defined
> in
> its are part of the dialog scope.
>
> Then the anonymous variable scope is defined as:
>
> "(anonymous)  Each <block>, <filled>, and <catch> element defines a new
> anonymous scope to contain variables declared in that element."
>
> This definition is in contradiction with the first definition which
> specified that the block element had its variables assigned into the
> dialog
> scope.
>
>
> Correction suggestion to section "5.1.2 Variable Scopes":
> "(anonymous)  Each <filled>, and <catch> element defines a new anonymous
> scope to contain variables declared in that element." (note block was
> removed from the description to make it consistent with the definition
> of
> the dialog scope)
>
> CR6-10 Resolution: accept with modifications
>
> We reject the suggested correction, but accept that a clarification is
> required in the definition of dialog scope, namely, that form element
> item names are being referred to.
>

I would like precisions on this because I don't well understand the VBWG
position on this issue. Can you please confirm that in the following VXML
document, the data logged by the <log> element should be 'dialog'? If this
is the case then I am satisfied with the VBWG response.

 <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
	 <form>
		 <var name="myVar" expr="'dialog'"/>
		 <block>
			 <var name="myVar" expr="'anonymous'"/>
		 </block>
		 <block>
			 <log expr="myVar"/>>
		 </block>
	 </form>
 </vxml>




> Issue CR12-2
> 2- out-of-date fetching algorithm: maxage defaults to property value
>
> Section "6.1.2 Caching" specifies the following:
>
> "[...]
> If a maxage value is provided,
> [...]
> Otherwise,
> If the resource has expired,
> Perform maxstale check.
> Otherwise, use the cached copy."
>
> I understand that the predicate "If a maxage value is provided" is
> always
> true, as there are default values for the different maxage properties
> (audiomaxage, documentmaxage, grammarmaxage, objectmaxage,
> scriptmaxage...) as
> specified in section "6.3.5 Fetching Properties"
>
> Suggested modification to section "6.1.2 Caching": remove the "If a
> maxage
> value is provided, " part and the corresponding "otherwise" statement.
>
> CR12-2 Resolution: rejected
>
> 'Provided' is equivalent to specified in this context: i.e. while there
> is always a platform-specific value, it is not always the case that a
> value is provided or specified in the document.

I am not satisfied with the VBWG response. Can you please clarify this
point. Do you mean that the algorithm could be rephrased as follows:

	If the resource is not present in the cache, fetch it from the server using
get.
	If the resource is in the cache,
		If a maxage value is **explicitly specified** in the document,
			If age of the cached resource <= maxage,
				If the resource has expired,
					Perform maxstale check.
				Otherwise, use the cached copy.
			Otherwise, fetch it from the server using get.
		Otherwise,
		If the resource has expired,
			Perform maxstale check.
		Otherwise, use the cached copy.

If so, can you then please describe what is the use of the "platform
defaults" for the fetching properties such as the sentence "The default is
platform-specific" for the "documentmaxage" in section "6.3.5 Fetching
Properties"?
If the intended behavior is the one described in the algorithm above, then I
suggest precising the extract semantic or removing altogether the default
value for the [document|audio|script|grammar]maxage properties.




> Issue CR14-1
>
> 1- Precise that timeout attribute of the <prompt/> element only applies
> if
> the prompt element is not empty
>
> The <prompt> element is designed to queue prompt element for play. As a
> side
> effect it also set the timeout for the next input collection. However,
> the
> specifications do not describe the expected behavior if the prompt
> element
> is empty: should tghe side-effect still apply? This would make little
> sense:
> this would be a synonym for a "set next timeout" command without
> queueing
> any prompt.
>
> Suggested addition to section "4.1 Prompts":
>
> "Note that an empty prompt such as "<prompt [...]/>" will be silently
> ignored and in particular would not set the timeout of the next input
> collection phase"
>
>
> Dependency: IR testsuite case #539 (389/389.vxml)
>
> CR14-1 Resolution: rejected
>
> The timeout property applies as normal even if there is no content in
> the prompt.
>

While I disagree with the VBWG resolution, I don't wish to register an
objection on this point.

Received on Monday, 24 November 2003 12:05:56 UTC