RE: [dialog] Berche #2 - VBWG official response to VoiceXML 2.0 Last Call Review Issues

The Voice Browser Working Group (VBWG) has almost
finished resolving the issues raised during the last call
review of the 24 April 2002 VoiceXML 2.0 [1]. Our apologies that 
it has taken so long to respond.

Although your comments were received outside the review period,
this is the VBWG's formal response to the issues you raised,
which have been logged in the Working Group's issues list [4].
The VBWG's resolutions have been incorporated into the 13 September
2002 draft of the VoiceXML 2.0 [5]. 

Please indicate before 18 October 2002 whether you are satisfied with
the VBWG's resolutions, whether you think there has been a
misunderstanding, or whether you wish to register an objection.
If you do not think you can respond before 18 October, please let me
know. The Director will appreciate a response whether you agree
with the resolutions or not.

Below you will find:

 1) More information follows about the process we are following.
 2) A summary of the VBWG's responses to each of your issues.

Thank you,

Scott
Co-Chair, VBWG

-----------------------------------------------
1) Process requirement to address last call issues
-----------------------------------------------

Per section 5.2.3 [2] of the 19th July 2001 Process Document, in
order for the VoiceXML 2.0 to advance to the next state (Candidate
Recommendation), the Working Group must "formally address all
issues raised during the Last Call review period (possibly
modifying the technical report)." Section 4.1.2 of the Process
Document [3] sets expectations about what constitutes a formal
response:

  "In the context of this document, a Working Group has formally
  addressed an issue when the Chair can show (archived) evidence
  of having sent a response to the party who raised the
  issue. This response should include the Working Group's
  resolution and should ask the party who raised the issue to
  reply with an indication of whether the resolution reverses the
  initial objection."

If you feel that the response is based on a misunderstanding of
the original issue, you are encouraged to restate and clarify the
issue until there is agreement about the issue, so that the
Working Group may prepare its substantive response.

If the response shows understanding of the original issue but
does not satisfy the reviewer, you may register a formal
objection with the Working Group that will be carried forward
with the relevant deliverables. 

[1] http://www.w3.org/TR/2002/WD-voicexml20-20020424/
[2] http://www.w3.org/Consortium/Process-20010719/tr.html#RecsCR
[3] http://www.w3.org/Consortium/Process-20010719/groups.html#WGVotes
[4] http://www.w3.org/Voice/Group/2002/voiceXML-change-requests.htm
(members only)
[5] http://www.w3.org/Voice/Group/2002/WD-voicexml20-20020913.htm
(members only)
(http://www.w3.org/Voice/Group/2002/WD-voicexml20-20020913.zip) (members
only)


-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------

In http://lists.w3.org/Archives/Public/www-voice/2002JulSep/0033.html
you raised the following issues registered as dialog change request
R511 respectively. Our response is given inline after each issue.

[1] Incorrect time designation pattern in schema: The time designation
pattern
"Duration.datatype" is defined as "\+?[0-9]+(m?s)?" in the schema.
However,
this does not include real numbers such as "1.5s" as specified by CSS2
section
"4.3.1 Integers and real numbers"

Suggested modification to the definition of "Duration.datatype" in the
schema:
 <xsd:restriction base="xsd:string">
  <xsd:pattern value="\+?[0-9]+(\.[0-9]+)?(m?s)?" />
  </xsd:restriction>

VBWG Response: Accepted.

Time designation pattern now correctly follows CSS2 model in [5].

[2] Precise the Exit expr attribute is an **ECMAScript** expression
which may
resolve into a defined variable Suggested text modification to section
"5.3.9
EXIT": 

"expr: An **ECMAScript** expression that is evaluated as the return
value (e.g. "0", "'oops!'", or "field1")."


VBWG Response: Accepted.

Change to be applied to next specification update. 


[3] Precise which event is thrown if the nextitem or expreitem attribute
of a
Goto element refers to a non-existing **form item**.

Suggested text modification to section "5.3.7 GOTO":
"If the **form item**, dialog, or document to transition to is not valid
(i.e. the **form item**, dialog or document does not exist), an
error.badfetch must be thrown. "


VBWG Response: Accepted.

Change to be applied to next specification update. 


[4] I also have a question concerning the "Mapping Semantic
Interpretation
Results to VoiceXML forms" that I could not answer. When an input item
contains a grammar with a dialog scope, would this grammar be considered
as a
form-level grammar (and therefore be semantically equivalent to a
grammar
element defined in the form) or would the interpretation of its results
be
different that a form-level grammar?  In particular, if this grammar
matches,
would the other input items be inspected for match of their slot names
on this
match?  If such a grammar is handled as a form-level grammar, I don't
quite
understand the benefit for developers to have it as a child of an input
item
rather than as a child of the form. Can somebody please point me to the
appropriate section in the specifications which detail this or provide
me with
details?


VBWG Response: Accepted.


Text is clear in [5], so no change. 

The distinction between field versus form level grammars is based on
where they defined, whilst scoping determines when they are activated.
So there is no direct connection between them - all field grammars only
fill its field variables, while form-level grammars can potential fill
any field within a form. 









-------------------
Scott McGlashan
 
PIPEBEACH
Box 24035/Linnégatan 89 B, 7tr
SE-104 50 Stockholm, Sweden
fax:       +46 8 54590993
office:    +46 8 54590990



www.pipebeach.com

Received on Wednesday, 9 October 2002 12:23:35 UTC