Copyright ©2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document details the responses made by the Voice Browser Working Group to issues raised during the Last Call (beginning 24 April 2002 and ending 24 May 2002) review of Voice Extensible Markup Language (VoiceXML) Version 2.0 . Comments were provided by Voice Browser Working Group members, other W3C Working Groups, and the public via the www-voice-request@w3.org (archive) mailing list.
This document of the W3C's Voice Browser Working Group describes the disposition of comment as of 29th November 2002 on Voice Extensible Markup Language (VoiceXML) Version 2.0 Last Call. It may be updated, replaced or rendered obsolete by other W3C documents at any time.
For background on this work, please see the Voice Browser Activity Statement.
This document describes the disposition of comments in relation to the Voice Extensible Markup Language (VoiceXML) Version 2.0 (http://www.w3.org/TR/2002/WD-voicexml20-20020424/). Each issue is described by the name of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.
The full set of Issues raised for the Voice Extensible Markup Language (VoiceXML) Version 2.0 since August 2000, their resolution and in most cases the reasoning behind the resolution are available from http://www.w3.org/Voice/Group/2002/voicexml-change-requests.htm [W3C Members Only]. This document provides the analysis of the issues that were submitted and resolved as part of the Last Call Review. It includes issues that were submitted outside the official review period, up to 1st October 2002.
Notation: Each original comment is tracked by a "(Change) Request" [R] designator. Each point within that original comment is identified by a point number. For example, "R5-1" is the first point in the fifth change request for the specification.
| Item | Commentator | Nature | Disposition |
| R419-1 | Teemu Tingander | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R426-1 | Teemu Tingander | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R426-2 | Teemu Tingander | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R426-3 | Teemu Tingander | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R467-1 | Lyndel McGee | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R468-1 | Lyndel McGee | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R469-1 | Deborah Dahl | Feature Request (§2.4) | Accepted |
| R469-2 | Deborah Dahl | Change to Existing Feature (§2.3) | Accepted |
| R469-3 | Deborah Dahl | Feature Request (§2.4) | Accepted |
| R469-4 | Deborah Dahl | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R470-1 | Stefan Hamerich | Change to Existing Feature (§2.3) | Accepted |
| R470-2 | Stefan Hamerich | Feature Request (§2.4) | Accepted |
| R470-3 | Stefan Hamerich | Change to Existing Feature (§2.3) | Accepted |
| R470-4 | Stefan Hamerich | Feature Request (§2.4) | Accepted |
| R471-1 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-2 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-3 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-4 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-5 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-6 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-7 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-8 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R471-9 | Matthew Wilson | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R472-1 | Bogdan Blaszczak | Change to Existing Feature (§2.3) | Accepted |
| R472-2 | Bogdan Blaszczak | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-1 | Guillaume Berche | Technical Error (§2.2) | Accepted |
| R477-2 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-3 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-4 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-5 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-6 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-7 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-8 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R477-9 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R478-1 | Al Gilman | Change to Existing Feature (§2.3) | Accepted |
| R478-2 | Al Gilman | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R478-3 | Al Gilman | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R478-4 | Al Gilman | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R495-1 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R495-2 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R495-3 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R495-4 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R495-5 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R495-6 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R496-1 | Guillaume Berche | Change to Existing Feature (§2.3) | Accepted |
| R496-2 | Guillaume Berche | Change to Existing Feature (§2.3) | Accepted |
| R502-1 | Teemu Tingander | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R503-1 | Teemu Tingander | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R505-1 | Ray Whitmer | Technical Error (§2.2) | Accepted |
| R505-2 | Ray Whitmer | Technical Error (§2.2) | Accepted |
| R505-3 | Ray Whitmer | Technical Error (§2.2) | Accepted |
| R505-4 | Ray Whitmer | Change to Existing Feature (§2.3) | Accepted |
| R507-1 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R507-2 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R507-3 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R511-1 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R511-2 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R511-3 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R511-4 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-1 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-2 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-3 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-4 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-5 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-6 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-7 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-8 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-9 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-10 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-11 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-12 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-13 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
| R519-14 | Guillaume Berche | Clarification / Typographical / Editorial (§2.1) | Accepted |
From Teemu Tingander
While reading spec 2.0 I found following "problem". --> Taken form W3C VoiceXML 2.0 draft in chapter 4.1.6 "Each form item and each menu has an internal prompt counter that is reset to one each time the form or menu is entered. Whenever the system uses a prompt, its associated prompt counter is incremented. This is the mechanism supporting tapered prompts." So the question is : Are prompt counts maintained for <form/> and <menu/> elements only or are they maintainded for each <*form item*> - specified in chapter 2.1.2 ? If we are working like in events; Counters are reseted when entering <form/> or <menu/> and we have individual counter for each <*form item*> , but initial uses <form/>s counters. This is right? So does this mean that when <goto item="this" /> occurs in field "that" while field "this" has prompt counter 3 the prompt that has count 3 is selected. So entering <field name="this">..</field> does not reset counter. So returning to <*form item*> that has prompted something before maintains <*form item*>s prompt count and allows us to do "tapared prompting", yeah ?
Resolution: Accepted
In Section 5.2.2 of the CR specification, we have clarified in the description of "count" attribute of <catch> when counters are reset: "The occurrence of the event (default is 1). The count allows you to handle different occurrences of the same event differently. Each <form>, <menu>, and form item maintains a counter for each event that occurs while it is being visited. Item-level event counters are used for events thrown while visiting individual form items and while executing <filled> elements contained within those items. Form-level and menu-level counters are used for events thrown during dialog initialization and while executing form-level <filled> elements. Form-level and menu-level event counters are reset each time the <menu> or <form> is re-entered. Form-level and menu-level event counters are not reset by the <clear> element. Item-level event counters are reset each time the <form> containing the item is re-entered. Item-level event counters are also reset when the item is reset with the <clear> element. An item's event counters are not reset when the item is re-entered without leaving the <form>. Counters are incremented against the full event name and every prefix matching event name; for example, occurrence of the event "event.foo.1" increments the counters for "event.foo.1" plus "event.foo" and "event".
Email Trail:
From Teemu Tingander
EVENT HANDLING: As Jean-Michel Reghem [reghem@babeltech.com] in his mail about events already pointed out there seems to be some unanswered questions in event handling in field elements. We seem to have 2 different kind of field elements from the event handling point of view This makes it difficult to application developer to always know where FIA's going. Solutions for these problems may be easily solved in FIA, but I hope that this is not the path that we want to follow. <object> is out from this discussion cause it already is quite difficult for application developer. In field elements <field> <initial> event thrown in collect phase ( like event "nomatch" ) prevents field to be filled unless otherwise assigned in catch handler and by doing this prevent <filled> execution. This makes sense to me. How ever handling events in <subdialog> this is not clear. The VXML 2.0 Draft specifications section 5.3.10 it is mentioned that ; "In returning from a subdialog, an event can be thrown at the invocation point, or data is returned as an ECMAScript object" and also after example : "The subdialog event handler for <nomatch/> is triggered on the third failure to match; when triggered, it returns from the subdialog, and includes the nomatch event to be thrown in the context of the calling dialog. In this case, the calling dialog will execute its <nomatch/> handler, rather than the <filled/> element, where the resulting action is to execute a <goto/> element. Under normal conditions, the <filled> element of the subdialog is executed after a recognized social security number is obtained, and then this value is returned to the calling dialog, and is accessible as result.ssn" It would clarify the thing quite if that example wouldn't have that <goto/> element. because it anyways causes FIA to exit. So should the field remain unfilled and visited again, like in <field>. I think that is should. BUT then we go to VoiceXML.orgs conformance examples and the first subdialog example. In my opinion it should end into endless loop. This would make sense in <field> like event handling. This needs to be clarified in specification. In the case of event; if field is not needed to be visited again <subdialog> elements cond change or <assign> to fill the field , like in <field>, could be used. The case with <record> element is almost the same as in <subdialog> but even more complicated . Lets start form FIA side of the view; As the specification says FIA only has 2 states : Processing input and document and Collecting user input ( Events OR Utterances ) The combining first and second example of <record/>: <?xml version="1.0"?> <vxml version="2.0"> <form> <record name="greeting" beep="true" maxtime="10s" finalsilence="4000ms" dtmfterm="true" type="audio/wav"> .. no change here .. </record> <field name="confirm" type="boolean"> .. no channge here .. </field> <catch name="telephone.disconnect.hangup"> <if cond="greeting"> <submit next="save_greeting.pl" method="post" namelist="greeting"/> </if> </catch> </form> </vxml> This comes much about the underlying system but I think that if there was something recorded on underlying layer ( in here we have to think silence detection etc. systems ) and then hang-up , the collection phase in field "greeting" should return the Utterance then on the collection phase for confirm the <event> telephone.hangup will be connected form underlying system and normal catch handling will take place. This is the case if collection phase produces only Events OR Utterances not BOTH. If I havent already brought it up I think that field gets filled only if event is not thrown in collection phase. < form> level <catch> will handle this quite neatly The field elment <transfer> is like <field> to me. Should it be ( so in case of blind transfer ) the event is handled and field is not filled. Hopefully that <catch> does the <exit/> or similiar. Is this the case with <disconnect>; in specification for <blind> transfer " The interpreter disconnects from the session and continues execution (if anything remains to execute) but cannot regain control of the call. The caller and callee remain connected in a conversation " This is all about event handling .. There were few clarifications about event counting issues that I pointer in my earlier mails.
Resolution: Rejected
We are unclear exactly what this issue is about since it spans a number of different points. Please re-formulate more clearly.
Email Trail:
From Teemu Tingander
DOCUMENT TRANSITIONS .. VXML 2.0 draft introduces more transitions within document, and some of these are not clearly explained. I would like to have some clarifications into specification to make application developers life little easier. I hope We all know the scoping of attributes and paramaters. Ill try to explain the problem. We have document 1 which is a Application Doc for doc 2 like on specs figure 3. In step 1 . Doc is an application root , but we dont know this at this time .. So should we initialize the variables in doc scope of doc 1 into scope document, Yes. But as said Root document is application by itself ( in spec Root2Root; "The root context is initialized with the new application root document, even if the documents are the same or have the same application name" ) so should variables ( and parameters ) in scope application be identical ( application == document ). ok. lets keep it this way. Should there be variables in scope application at all ? In Step 2. The doc scope should be replaced with variables for leaf doc 2. Right because this is the "doc" that we are executing . Yep This is easy. In Step 3. Same thing but with variables form doc 3 In Step 4. Do we just need to copy variables and parameters from scope app -> doc because they are the "doc" variables of this document. This is my interpretation of Specification i hope that it is right. So. I would like the changes in scopes to be clarified in case of Root2Leaf And Leaf2Root transition.
Resolution: Accepted
We have clarified in Section 5.1 of the CR specification that: "Note that while executing inside the application root document document.x is equivalent to application.x.".
Email Trail:
From Teemu Tingander
LINKS (CHOICES) AND CATCHES As specified the <link> element ( also <choice> ) has three attributes that are derived from other components ( or should I say shorthand ) , event next and expr so: <link dtmlf="0" next="something" /> <link dtmlf="0" expr="'something'+'something'" /> <link dtmlf="0" event="help" /> They could be implemented as - The first 2 cases: <link dtmlf="0"> <goto next="something"/> </link> or <link dtmlf="0"> <throw event="help"/> </link> I think that this would be more clear what happens. and would make it possible to use <submit> too. In <choice> elements this could be little tricky, but would work also. This approach would make it possible to support <log> tag inside link too. And what it comes to links it seems to me that they share lots of common with catches - they catch an invocation to their grammar and process throw or goto .. almost like <catch grmr="link1_grmr"> <goto next="something"/> </catch> or <catch event="link1_grmr"> <goto next="something"/> </catch> Cause in link it is only needed to know what grammar triggered. So catch and link are special cases of catch ? Another thing is <prompt> , and to me it is a Big thing :) I would like to know why it is permitted to write "prompts" without proper tagging. I personally think that this wouldn't change the way how pages are made radically if <prompt>- tags would be mandatory; It would clarify the content quite a much.
Resolution: Rejected
While you are correct that there are similarities between <link> and <catch>, <link> is a simplified form and we want to keep it as simple as possible. If you want to do more powerful things with a <link>, then you can use a document-scope <form> instead.
Email Trail:
From Lyndel McGee
Section 2.1.5 specifies (the 2nd sentence): " To make a form mixed initiative, where both the computer and the human direct the conversation, it must have one or more <initial> form items and one or more form-level grammars. " That implies that <initial> is a required element of the mixed-initiative form. The examples use <initial>, too. However, FIA does not seem to have any provisions to enforce it. Our questions: - Is <initial> required for a form to be mixed-initiative ? - Or, does a form-level grammar alone imply mixed-initiative? If <initial> is not required, then there seem to be no benefit in defining directed and mixed-initiative forms (a VoiceXML language structure). Instead, the directed and mixed-initiative behaviors should be discussed in terms of item modality and grammar types and scoping (VoiceXML use cases). For example, the following language could be used: - A 'directed dialog' can be implemented by using form item-level grammars rather than form-level grammars. If it is desired to restrict user options to just the item's grammar, the form item should be made modal. Otherwise, grammars in wider scopes may still accept user utterances (eg. links with 'restart', 'new order', etc.) and restart interpretation at a different form. - A 'mixed-initiative dialog' can be implemented by using form-level grammars that may return multiple slots and thus allow multiple form items to be filled from a single caller utterance. The <initial> form item can be used in this scenario to prompt for and collect an utterance before executing any input items of the form (which may have their own specialized grammars and may potentially capture the recognition results as their own input). Otherwise, if <initial> is required for a form to be mixed-initiative, a form without <initial> would be a directed form regardless of the presence of a form-level grammar. In such case, any utterances would be processed in the context of individual input items rather than in the form context. The form items will be filled one at a time.
Resolution: Accepted
In the CR specification, we have clarified that (a) mixed initiative is a style of dialog (not a form sub-type), and (b) that <initial> isn't necessary for mixed-initiative dialog but one way of doing it. In particular, the first paragraph of 2.1.5 now reads: "The last section talked about forms implementing rigid, computer-directed conversations. To make a form mixed initiative, where both the computer and the human direct the conversation, it must have one or more form-level grammars. The dialog may be written in several ways. One common authoring style combines an <initial> element that prompts for a general response with <field> elements that prompt for specific information. This is illustrated in the example below. More complex techniques, such as using the 'cond' attribute on <field> elements, may achieve a similar effect.
Email Trail:
From Lyndel McGee
Let's consider interpretation of a VoiceXML document where: - there is a form with multiple fields, - the form has a form-level grammar that can return multiple slots, - the fields do not have their own grammars, - it is a mixed-initiative form (see also the problem #1 above), - the first recognition result fills some fields, but not all of them, - another caller utterance is needed to fill the remaining fields. Our questions: [a] - Is it expected that the form will switch to the 'directed dialog' mode after the first utterance and then consider only unfilled items for the subsequent utterances (see also problem #1 above) ? [b] - Or, will the form remain in the 'mixed-initiative dialog' mode and will user utterances continue to be mapped to multiple input fields (as the 2nd table in section 3.1.6.3 seems to imply) ? [c] - And, if the form is to remain in the 'mixed-initiative dialog' mode, can the next user utterance overwrite fields that have been already filled or will those fields retain their previous values ? To illustrate the problem, let's assume that: - the fields are 'size', 'color', and 'shape', - the first utterance is 'big square', - the second prompt says 'Please provide the color', - the second utterance is 'blue triangle'. Will the completed form be 'big blue square' or 'big blue triangle' ? The 2nd table in section 3.1.6.3 should be updated to cover all (canonical) combinations of user input and dynamic states of form components.
Resolution: Accepted
[a] and [b] don't require spec changes; Accepted [c]. See response to R467 for clarification of terms 'directed dialog' and 'mixed initiative dialog'. [a]/[b]: Given you only have a form-level grammar in your example, it is the only grammar that can be matched by user input. When the FIA visits the form, it will go to the prompts in an <initial> if present, read out the prompts in <initial> and activate the form-level grammar. If there is no <initial>, it will go to the first field and do the same thing there. After the first recognition fills in some but not all fields, the <initial> can no longer be visited, and the FIA will go to the next unfilled field, queuing its prompts and again activate the form-evel grammar (there are no other grammars in your example!). This will continue until all fields are filled. [c] We have clarified in 3.1.6.1 of the CR specification that matching form-level grammars can override existing values in input items and that <filled> processing of these items takes place as described Section 2.4 and Appendix C.
Email Trail:
From Deborah Dahl
Grammar tag's content model Section 3.1.1 should state explicitly that the SRGS grammar tag is extended to allow PCDATA for inline grammar formats besides SRGS. It currently says that SRGS tags including grammar have not been redefined. Priority: High
Resolution: Accepted
We have clarified in Sections 3.1.1 and 3.1.1.4 of the CR specification that the SRGS <grammar> element is extended in VoiceXML 2.0 to allow PCDATA for inline grammar formats besides the XML format of SRGS.
Email Trail:
From Matthew Wilson
The index between Appendix N and Appendix P appears to be Appendix zero, not Appendix O.
Resolution: Accepted
Corrected in CR specification.
Email Trail:
From Matthew Wilson
In section 6.5, "Time Designations", the example "+1.5s" still contradicts the text, which describes the format as "an unsigned number followed by an optional time unit identifier".
Resolution: Accepted
Clarified in section 6.3 that a time designator is a non-negative number which must be followed by ms or s (i.e. it is fully aligned with Time in CSS2).
Email Trail:
From Matthew Wilson
Section 2.1.2.1 "Input Items" says that "implementations must handle the <object> element by throwing error.unsupported.object.objectname if the particular platform-specific object is not supported". Section 2.3.5 "OBJECT" says that "implementations must handle the <object> element by throwing error.unsupported.object if the particular platform-specific object is not supported" (i.e. it does not include the object name in the event name). Section 5.2.6 "Event Types" does not list any error.unsupported.object events, but does include error.unsupported.format, which is raised if "The requested resource has ... e.g. an unsupported ... object type". Could this be clarified?
Resolution: Accepted
In CR specification, changed and clarified in sections 2.1.2.1 and 2.3.5 that if an implementation does not support a specific object, it throws error.unsupported.objectname. In section 5.2.6 that the event error.unsupported.format is not thrown for unsupported object types. The section 5.2.6 is not intended as an exhaustive list of event types (no change).
Email Trail:
From Matthew Wilson
Events such as error.unsupported.uri, error.unsupported.language, error.unsupported.format are ambiguous, since they could also be occurrences of error.unsupported.<element> if incorrect elements have been used in the VoiceXML document.
Resolution: Accepted
Clarified 5.2.6 by adding that <element> in error.unsupported.<element> refers to "elements defined in this specification."
Email Trail:
From Matthew Wilson
Section 6.1.2.1 says that "VoiceXML allows the author to control the caching policy for each use of each resource." Is this true of the application root document?
Resolution: Accepted
Clarified in 6.1.2.1 that there is no markup mechanism to specify the caching policy on a root document.
Email Trail:
From Matthew Wilson
Regarding the "builtin" URI scheme, http://www.w3.org/Addressing/schemes#unreg says that "Unregistered schemes should not be deployed widely and should not be used except experimentally." Is there any intention to register the "builtin" scheme?
Resolution: Accepted
We are still trying to determine if there is an existing URI scheme which we can reuse for VoiceXML builtin. If we are unable to find one, then we will register the builtin scheme.
Email Trail:
From Matthew Wilson
There is a typo "attibute" in the schema in Appendix O (in the xsd:annotation for the Accept.attrib attributeGroup).
Resolution: Accepted
Corrected.
Email Trail:
From Matthew Wilson
The "minimal Conforming VoiceXML document" in appendix F1 is not minimal. As the text itself states, the XML declaration, and the xmlns:xsi and xsi:schemeLocation are not rqeuired for conformance.
Resolution: Accepted
In appendix F, changed description of example so that it is not described as minimal.
Email Trail:
From Matthew Wilson
Section 5.1.3 says, when referring to XML-escaping characters such as <, >, and & : "For clarity, examples in this document do not use XML escapes." I strongly disagree with this decision. I think that having examples in the spec which do not work is more likely to lead to confusion than anything else. If there is a lack of clarity in VoiceXML in places, then I believe the spec should not try to hide the fact.
Resolution: Accepted
Removed this text and updated all examples to escaped XML characters.
Email Trail:
From Bogdan Blaszczak
A standard solution for a playback control can be based on SSML ideas. For example, VoiceXML may allow additional attributes to be used in the <audio> tag. Such attributes can be modeled on selected attributes of <prosody> (see also section 2.2.4 of the SSML spec). The attributes would be optional and possibly ignored by some platforms. The following additional <audio> attributes would be useful: - speed: the playback speed in percent of the normal speed (e.g.:50%, 100%, 200%) or values 'slow', 'normal', 'fast'. - volume: the playback volume in percent of the normal volume (e.g.:50%, 100%, 200%) or values 'soft', 'normal', 'loud'. - position: the playback start position in seconds from the beginning of the audio recording (e,g.: 1s, 100s).
Resolution: Rejected
This issue has been discussed many times by the team, and has been decided as beyond the scope of VoiceXML 2.0. However, it could be addressed in the next version of VoiceXML.
Email Trail:
From Guillaume Berche
In section 4.1.5, when playing prompt with a false bargein attribute, are matching DTMF or speech input buffered or discarded? Suggested fix: in section 4.1.5, modify the text to "When the bargein attribute is false, any DTMF input buffered in a transition state is deleted from the buffer (Section 4.1.8 describes input collection during transition states). In addition, while in the waiting state and a prompt whose bargein attribute is false, any user input (speech or DTMF) is simply ignored."
Resolution: Accepted
Clarified in section 4.1.5 that when a prompt's "bargein" attribute is false, no input is buffered while the prompt is playing (any DTMF already buffered is discarded).
Email Trail:
From Guillaume Berche
It is not clear whether DTMF input which does not match currently active grammars should interrupt a prompt whose bargein attribute is true Suggested fix: In section 4.1.5, correct the the first sentence with the following: "If an implementation platform supports barge-in, the application author can specify whether a user can interrupt, or "barge-in" on, a prompt using speech or DTMF input. In the case of DTMFs, any input (even not matching active grammar) will interrupt a prompt, and will be handled in the same way as non matching DTMFs entered outside of a prompt."
Resolution: Accepted
We have a slightly different solution, though. We have clarified in section 4.1.5.1 that the "bargeintype" attribute of <prompt> applies to DTMF input as well as speech input.
Email Trail:
From Guillaume Berche
Just clarify 4.1.5 with respect to interruption of a chain of queued prompts Suggested fix: in section 4.1.5, modify the text to: "Users can interrupt a prompt whose bargein attribute is true, but must wait for completion of a prompt whose bargein attribute is false. In the case where several prompts are queued, the bargein attribute of each prompt is honored during the period of time in which that prompt is playing. If bargein occurs during any prompt in a sequence, all subsequent prompts are not played **(even those whose bargein attribute are set to false)**."
Resolution: Accepted
Edit applied.
Email Trail:
From Guillaume Berche
Analysis:For completeness and convenience, an extract from section 4.1.5 below should be reproduced or at least mentionned in section 4.1.8. Suggested fix: add the sentence below before "Before the interpreter exits all ..." "As stated in section 4.1.5, when the bargein attribute is false, any DTMF input buffered in a transition state is deleted from the buffer".
VBWG: Rejected. We didn't see a clear use case or motivation for this change. Berche: The motivation for my comment is that information is spread around in the specification. My feedback is that it is often hard to have a good understanding of the behavior of the language because general behavior such as input processing is scattered in different sections. Adding such cross references would make the specifications easier to read and understand. In the specific case of this request, the section "4.1.8 Prompt Queueing and Input Collection" provides a general description of the algorithm and state the interpreter uses to process input and play prompts. However it omits the description of bargein which impacts both input processing and prompt queueing.
Resolution: Accepted
Added in Section 4.1.8 a cross-reference to Section 4.1.5.
Email Trail:
From Guillaume Berche
Concerning ECMAScript variables holding non-scalar values (such as field item variable for a record fieldaudio, or the special _prompt variable as mentionned in my previous mail) - what ECMAScript type do they have? Is it indeed an ECMAScript an host object as defined in the ECMAScript specifications (or Array object containing other objects in the case of the _prompt variable). If so, what is their exact list of properties along with their type and properties (ReadOnly, DontEnum, DontDelete, Internal)?. As a side-question, what does the ECMAScript typeof operator returns on these objects? Concerning ECMAScript special variables (such as <name>$.<shadow_var> in fields) - can they be modified by (of as a side effect of) ECMAScript code evaluation (such as evaluating a guard condition, or an expr attribute)? Suggested fix: Add a specific section about ECMAScript evaluation. This section could precise runtime error that occur during ECMAScript evaluation, possible side-effects of ECMAScript evaluation (such as cond attribute evaluation), and also the type of shadow variables with the text below: "Shadow variables are host objects as defined in the ECMAScript specifications. The properties of these shadow variables are read-only. Any attempt by some ECMAScript code evaluation (either in a script element or as a side effect of the evaluation of an expr attribute) to modify those properties will result in an error.semantic to be thrown"
Resolution: Rejected/Accepted
Many questions here! The properties of ECMAScript variables in VoiceXML are not specified unless necessary. With <record>, we have clarified that its implementation is platform-dependent (so different implementations can have different ECMAScript properties) but that all must playable by <audio>, submittable by <submit> and so on as described in the specification. For shadow variables, we have clarified that they are writable, so they can be modified. For runtime errors encountered during the FIA, we have clarified that in the FIA Appendix.
Email Trail:
From Guillaume Berche
Section 2.2 describes that the _prompt special variable "is the choice's prompt". The type of this variable is fuzzy and the specs does precise the behavior of <value expr="_prompt"/> in case where a choice element would contain mixed audio prompts and TTS. Suggested fix: add the following text to section 2.2 in the enumerate element section: "This specifier may refer to two special variables: _prompt is the choice's prompt, and _dtmf is the choice's assigned DTMF sequence. The _prompt special variable is a host object which has no visible properties and should only be used within a <value expr="_prompt"> element. If the choice contained more than one prompt element (such as TTS elements, or a nested <value> element) then executing the <value expr="_prompt"> would queue all of the prompt elements and would also execute the nested <value> element. If the nested <value> element references itself the _prompt variable, this would lead to an infinite recursive loop, that interpreter may detect and handle by throwing an error.semantic event. The _dtmf special variable is of type string and may be used as such by ECMAScript code within the expr attribute of the <value> element."
Resolution: Rejected
The assumption that the <choice> element can contain SSML is no longer true: in the CR version of specification a <choice> element can now only contain CDATA.
Email Trail:
From Guillaume Berche
Clarification to FIA with respect to run-time errors: When the evaluation of a guard condition results in a run-time exception, how does this modify the FIA. The FIA algorithm in appendix C seems to only consider exceptions generated during the execution phase and remains fuzzy about those that occur during previous phases (such as initialization, queuing of prompts such as <value>, evaluation of guard condition) Suggested fix: modify the FIA so that it state that "any runtime error occuring during the select phase (e.g. runtime error to evaluate guard condition), collect phase (e.g. runtime error at prompt queuing for instance during <value> element execution) up to the input collection result in the control being directly passed onto the process phase."
Resolution: Accepted
Clarified that FIA handles run-time errors in all phases.
Email Trail:
From Guillaume Berche
In the FIA, appendix C, for the collection of active grammars when not modal, it says that these include "elements up the <subdialog> call chain." This seems to be in contradiction with the section on <subdialog> which says each subdialog has a totally separate context from the caller, and shares/inherits absolutely no elements with it. Suggested fix: Remove the "and then elements up the <subdialog> call chain." from the FIA description.
Resolution: Accepted
Correction applied.
Email Trail:
From Al Gilman
Analysis:Voice is center, not limit, of domain of application. [reference: Appendix H] The appendix paints the applicability of this technology too narrowly. Even in cases where the dialog designer only thinks in a voice dialog context, the resulting dialogs have been thought through thoroughly and are expected to be, for example, - highly usable as transcoded into a text-telephone delivery context - likewise as transcoded into a Braille environment for those who are both deaf and blind. The idea that this technology is 'final form' should be eliminated and the language brought more in line with that in section 2.1 of the latest Member draft of the Speech Recognition Grammar Specification where it touches on this point.
The current accessibility appendix H is not acceptable to them. They have offered to provide a re-working of it where voice is center, but not limit, of domain of application (fits in with the goals of text input/output for accessibility). VBWG Response: Accepted.
Resolution: Accepted
PFWG provided the draft of a re-written Appendix H: Accessibility. This was subsequently edited, reviewed by the PFWG and then incorporated into the CR specification. This appendix also includes additional guidelines for enabling persons with disabilities to access VoiceXML applications.
Email Trail:
From Al Gilman
Analysis:a. Completeness of key-access to function. Control of the application through key-presses by way of DTMF catches allows people with unrecognizable speech access to the application. Can the format specification enforce complete functionality in this mode of interaction? If it can, the group should consider requiring this. If not, we should discuss a lower minimum requirement including orientation to alternate modes of accessing the same operational service through another channel of communication (like giving an 800 number on your website). b. Always define a global ENTER user-action. [reference: 3.1 Grammars] The functionality intended here is that there is something the user can do that serves as an executeImmediate or justDoIt verb. Comparable to the use of the ENTER key on desktop keyboards. This could be 'Yes, please' in an English speech catch grammar, the hash (#) key in DTMF, or what you like. This mode of operation is used by people with severe motor limitations in accessing computer applications. The same "wait and act" mode of user action that they use there is adaptive here in the same personal circumstances and for the same reasons. http://www.abilityhub.com/switch/ Key-bindings that might make sense to standardize in this specification include this function and zero (0) for Help.
PFWG prefer that VoiceXML documents have 'DTMF functional completeness': for all inputs by speech, there is an equivalent DTMF input.
Resolution: Rejected
Specific reasons against this approach: (a) The application of speech recognition as an input medium is severely limited if there always needs to be a DTMF equivalent grammar. Speech provides a natural, 'wide' interface which is very difficult, if not impossible in mixed-initiative applications, to capture with DTMF input due to the limited token set and syntax of DTMF. (b) The menu structure of DTMF input can be very different from the menu structure allowed by speech input. It is unclear how these structures can be reconciled by requiring DTMF grammars to parallel speech grammars. (c) The prompts will need to be different: DTMF input patterns need to be explained and taught to the user, while speech is more intuitive and complex, explanatory prompts are not required. Providing both simultaneously leads to prompts which can be highly confusing for the end user. (d) There are alternative mechanisms available today to provide DTMF input in addition to speech input, including (i) providing an alternative DTMF only dialog within the same VoiceXML document, or (ii) providing an alternative VoiceXML application (for example by means of a separate telephone line). (e) It is unclear how this requirement would be enforced, and grave doubts about whether it would be complied with. (f) The alternative of using SRGS with text rather than speech input provides a better alternative since it allows a wider input channel than DTMF. (h) It is unclear how DTMF would address internationalization, which SRGS input addresses. In summary, the VBWG felt that it was inappropriate to use W3C technology specifications to enforce this type of policy. Guidelines describing best practise for accessibility with respect to Voice Browser are prefered. It was also unclear whether this policy is within the scope of W3C at all - further clarification and guidance from W3C management is required.
Email Trail:
From Al Gilman
5. Regular, proven and familiar dialog structures. [reference: 3.1 Grammars] The above specific device is a special case of a broader issue. This has to do with creating simple, regular navigation structures that are highly usable and leverage learning across multiple applications that use the same best practices. Compare with http://www.w3.org/TR/WCAG10/#gl-facilitate-navigation In addition to the general concept set forth in this guideline, the following two examples of reference designs which have been developed for delivery contexts that stress the mnemonic appeal of the dialog flow are worth noting: Website design for those with severe learning disabilities: http://www.learningdisabilities.org.uk/html/content/webdesign.cfm Note in particular the five global functions in this dialog design. Navigation modes for the ANSI/NISO X39-86-2002 Digital Talking Book Standard. Start at http://www.loc.gov/nls/niso/ Some preliminary experience with designing VoiceXML applications with this as the general operational model have been highly encouraging. 6. Complete safety net. [reference: 1.3.5 Events 1.5.4 Final Processing 5.2 Event Handling 5.2.2 Catch 5.2.4 Catch Element Selection 5.2.5 Default Catch Elements] Each element in which an event can occur SHOULD specify catch elements, including one with a fail-soft or recovery functionality. Examples: <catch event="noinput"> <reprompt/> </catch> <catch event="nomatch"> <audio> I am sorry.,.I did not understand your command. Please re-enter your key choice. </audio> <reprompt/> </catch> <catch event="help"> Please say visa, mastercard, or amex. </catch> 7. Timeouts [reference: Appendix D - Timing Properties 4.1.7 Timeout] People with disabilities sometimes need a little extra time to respond or complete an input action. Generous time allowances should be available. Prompt user that the timeout will expire, give option to extend time. Making extra time available as an ask-for option may be the most effective way to a) keep the application accessible to those who need it without b) impairing the functionality for others through excessive delays. 8. Human or other option. [reference: 1.5.2 Executing a Multi-Document Application 5.3.9 EXIT] Advertise alternate modes through which comparable service is available. This may involve transfer to a human operator, text telephone service through transfer or re-dial, etc. Particularly during final processing as safeguard. Examples: Specify (or allow for) a "wait" or "help" for barge-in during final processing, with an option to <transfer> to a human operator. "Goodbye" (computer) "wait....wait!" (human) "Would you like me to repeat your new account number?" (computer) "Yes....I didn't get it the first time" (human) "The new account number established during this call for Mary Jane Jones, is 6652281. Does this answer all your questions?" (computer) "Yes" (human) "If you need to speak with an operator, just say "Operator". Would you like to transfer to an operator?" (computer) "No" (human) "Thank you for using the National Bank's automated voice system. Goodbye" ** DON'T LOSE THESE KEY FEATURES We couldn't resist the following affirmations. Please take these as a "Not just yes, but He** yes!" response: These features and design aspects will prove critical in disability access situations: 9. Layered help. [reference: 2.3 Form Items 2.5 Links 3.1.1.3 Grammar Weight 4.1.6 Prompt Selection 5.2 Event Handling 5.2.2 Catch 5.2.5 Default Catch Elements 5.2.6 Event Types 5.3 Executable Content] This is good. Thank you. Get people to use it. Example: Example: aMenu[1].items[0].helptext = "If this is the entry you want please press the pound key"; aMenu[1].items[0].morehelptext = "Press 1 to start over"; 10. Application-scope grammars. Best to specify application-scope form grammars in the root of a multi-document application. IMPORTANT: It is stated in the document body , as well as in the "Clarifications" section why this is a good idea in general. This goes redoubled for accessibility.
Resolution: Accepted
After consultation with the PFWG, it was agreed that this issue is more concerned with application design guidelines rather than the specification itself. In the current specification, Appendix H: Accessibility includes some basic guidelines. The VBWG and PFWG have initiated joint work on further expanding on these guidelines into separate 'Voice Design Guidelines' document.
Email Trail:
From Guillaume Berche
Precise the execution of catch handlers in section "5.2.2 Catch" Section "5.2.2 Catch" seems to imply that handlers are called synchronously: "If a <catch> element contains a <throw> element with the same event, then there may be an infinite loop: <catch event="help"> <throw event="help"/> </catch>" Suggested text addition: "The FIA appendix C details the execution after a catch element is executed (in its definition of the "execute" term)"
Resolution: Rejected
Unclear what the problem is: we don't see any inconsistency between the 5.2.2 text and the FIA.
Email Trail:
From Guillaume Berche
Precise the definition of "execution" in the FIA appendix C to executables from handlers. Suggested text modification: "execute To execute executable content either a block, a filled action, or a set of filled actions. If an event is thrown during execution, the execution of the executable content is aborted. The appropriate event handler is then executed, and this may cause control to resume in a form item, in the next iteration of the forms main loop, or outside of the form. If a computed-directed transition element(such as <goto>, <link>, <return> or <submit>) is executed, the transition takes place immediately, and the remaining executable content is not executed. During the execution of the event handler, the same rule applies as for the execution of executable content described above (with respect to execution abortion and transition)."
Resolution: Accepted
We have already clarified execution of executable context in response to other requests. Note that <link> cannot appear in executable context.
Email Trail:
From Guillaume Berche
Precise error handling during document initialization (e.g. in document-level <script> and <var> elements) Suggested modification: Move the modified following text from section "5.2.6 Event Types" to section "5.2.2 Catch" (or to a new section, as suggested in comment #4) "Errors encountered during document loading, including transport errors (no document found, HTTP status code 404, and so on) and syntactic errors (no <vxml> element, etc) result in a badfetch error event raised in the calling document, while errors after loading (including document initialization) (such as semantic errors during <script> and <var> initialization), are raised and handled in the document itself." I could not understand the rationale behind the following statement in section "5.2.6 Event Types", near to error.badfetch. "Whether or not variable initialization is considered part of executing the new document is platform-dependent." Can please someone explain why this behavior would be platform dependent?
Resolution: Accepted
We have added the following text to the 5.2.6: "Errors encountered during document loading, including transport errors (no document found, HTTP status code 404, and so on) and syntactic errors (no <vxml> element, etc) result in a badfetch error event raised in the calling document. Errors that occur after loading and before entering the initialization phase of the Form Interpretation Algorithm are handled in a platform-specific manner. Errors that occur after entering the FIA initialization phase, such as semantic errors, are raised in the new document. The handling of errors encountered during the loading of the first document in a session is platform-specific." Variable initiatization may be platform-dependent since a platform may use a SAX-based document construction technique where initiation of variables takes places as each statement is reached during document loadin, or may use a DOM-based technique where the whole document is constructed first, then any initialization takes place.
Email Trail:
From Guillaume Berche
Precise document initialization. As described above in comment #3, some events are handled at document initialization. However, since elements are initialized in document order, events handlers may not yet be active at the time an event is thrown. Take for instance the usual case of a vxml document starting with a script element: no document handlers are yet initialized, and an error in the <script> element would not be handled by defined event handlers. Suggested modification: add a specific section concerning document initialization similar to the FIA which precise the order of element initializations "1.5.0 Document initialization Document initialization starts once the transport and XML schema validation has been performed. As described in section "5.2.2 Catch", errors occuring during this phase are raised and handled in the document itself. During handling of events, the variable scope chain may not be complete (there might be no chained dialog scope yet), but the _event shadown variable is still defined in an anonymous variable scope" Each element is initialized in document order including event handlers. Consequently, it is advised to define document-level handlers first in the document. ... Once all elements are initialized, the document execution begins. As described in section "1.5.1 Execution within One Document", document execution begins at the first dialog by default. "
Resolution: Accepted
We have clarified in the FIA Appendix the description of initialization: "foreach ( <var>, <script> and form item, in document order ) if ( the element is a <var> ) Declare the variable, initializing it to the value of the "expr" attribute, if any, or else to undefined. else if ( the element is a <script> ) Evaluate the contents of the script if inlined or else from the location specified by the "src" attribute. else if ( the element is a form item ) Create a variable from the "name" attribute, if any, or else generate an internal name. Assign to this variable the value of the "expr" attribute, if any, or else undefined." and clarified error handling during FIA execution: "During FIA execution, events may be generated at several points. These events are processed differently depending on which phase is active. Before a form item is selected (i.e. during the Initialization and Select phases), events are generated at the dialog level. The corresponding catch handler is located and executed. If the catch does not result in a transition from the current dialog, FIA execution will terminate. Similarly, events triggered after a form item is selected (i.e. during the Collect and Process phases) are usually generated at the form item level. There is one exception: events triggered by a dialog level <filled> are generated at the dialog level. The corresponding catch handler is located and executed. If the catch does not result in a transition, the current FIA loop is terminated and Select phase is reentered." Note that XML Schema validation is NOT compulsory in VoiceXML (see Appendix F - Conformance).
Email Trail:
From Guillaume Berche
Refine anonymous variable scope during event handling Section "5.2.2 Catch" states that "The catch element's anonymous variable scope includes the special variable _event which contains the name of the event that was thrown." To me, this implies that the handler is invoked when the FIA is currently running (that is a form and a form item are active). However, this might not be the case for events handled during document initialization. Consequently, the variable scope chain as described in section "5.1.2 Variable Scopes" would not work, in particular there would no chained dialog scope. Suggested modification is included in comment #4.
Resolution: Rejected
We don't see the 'implication' that the existent of the _event variable implies the FIA is currently running.
Email Trail:
From Guillaume Berche
Precise that a <field> item without implicit nor explicit grammar should throw an error.semantic event. See if it is possible to refine the schema to enforce this. Alternative suggested text modification to the end of section "2.3.1 FIELD" "[...] The use of <option> does not preclude the simultaneous use of <grammar>. The result would be the match from either 'grammar', not unlike the occurence of two <grammar> elements in the same <field> representing a disjunction of choices. However, a field item without implicit nor explicit grammar would result in an error.semantic event to be thrown at document initialization time".
Resolution: Rejected
The specification doesn't state or imply that a field without grammars is an error, so we cannot make it more precise.
Email Trail:
From Teemu Tingander
Case was this : <field name="order" /> <prompt> Make Your Order </prompt> <grammar mode="voice" src="order.grxml" type="application/srgs+xml"/> <filled> <submit src="someurl" mode="???"> </filled> </field> So if the order is filled with structured object like : order: { drink: "coke" pizza: { number: "3" size: "large" topping: [ "pepperoni"; "mushrooms" ] } } what is the correct way to create POST request and GET request.. like in GET: http://someurl?order.drink=coke&order.pizza.number=3 &order.pizza.number=3&or der.pizza.size=large&order.pizza.topping=pepperoni &order.pizza.topping=mushrooms Issues rise on arrays (order?); should they be numbered etc. ? The post request is more complicated to write so i leave it of from here.
Resolution: Accepted
VoiceXML 2.0 in April 2002 specification makes it clear that developers should decompose object themselves for submission, see Section 5.3.8 (default submission: stringOf on object). Decomposition as you suggest is reasonable and since you control the recomposition at the other end, any issues with arrays, etc you should be able to resolve yourself.
Email Trail:
From Teemu Tingander
What is the scoping of properties ? how many, what is the top( field? ) scope. And expr for property would be nice and very usefull while tuning ASR throught <properties>. Should property reset back what it was in previous scope! or scope attribute for <property > like scope (universal | document | form | dialog | location) "location" what specifies how "deeply" it affects. <?xml version="1.0"?> <vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"> <property name="noicefilter" value="small"/> <form id="first"> <field name="location"> <property name="noicefilter" value="large"> <prompt> Say the location of the person you would like to call. </prompt> <filled> <if expr="location$.noicelevel > 0.3"> <!-- property name="noicefilter" value="huge"/ --> <prompt> Please repeat</prompt> <clear/> <else/> <goto next="#second"> </if> </filled> </field> <! -- second case how it should work if filled would be here > </form> <form id="second"> <! -- it would be nice to have that propery as "huge" here by default if it is noicy env.! --> <field name="location"> <prompt> Say the second location of the person you would like to call. </prompt> </field> <filled next="#second"> </form> </vxml> is the flow following 1- setProperty ( DOC.scope, "noicefilter", "small" ) 2- setProperty ( FIELD.scope, "noicefilter", "large" ) 3- Say the location of the person you would like to call. 4(?)- Field gets filled, with high noice level (just example shadow variable, could be confidence or... ) 5 - FIA exits field scope, goes 2 form scope 6 - propery noicefilter resets to small, cause it was it in doc scope. 7 - FIA searches field location, enters it and sets setProperty ( FIELD.scope, "noicefilter", "large" ) 8 - gets filled, executes, goes to #second 9 - propery noicefilter resets to small, cause it was it in doc scope. 10 - .... Is this what You had in mind ?
Resolution: Rejected
The team has already discussed adding an expr attribute on property and has previously rejected it. The scope of properties is described at beginning of Section 6.3 and it seems to be consistent with your description.
Email Trail:
From Guillaume Berche
Precise the behavior if Reprompt is executed outside of a catch element Suggested text addition to section "5.3.6 REPROMPT": "If a Reprompt is executed outside of a catch element (such as in a block or filled elements) then an "error.semantic" event is thrown.
Resolution: Accepted
It has been clarified that a <reprompt/> outside a catch has no effect (since the FIA performs normal selection and queuing of prompts outside catches).
Email Trail:
From Guillaume Berche
Precise which event should be thrown for malformed ECMAScript expressions in Var, Assign, Script, and ECMAScript expression evaluation (such as the "cond" attribute, and expr attribute variants). Suggested text addition to Appendix C, FIA: "During the execution of the FIA, various ECMAScript expressions are evaluated such as the "cond" attribute of input or prompt items and the different variants of "expr" attribute. If the evaluation of such an ECMAScript expression