[dialog] Blaszczak - 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.

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 3 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 3 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

-----------------------------------------------
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/2002AprJun/0068.html
you raised 
the following issues which were registered as dialog change request
R472. 
Our response is given inline after each issue.
 
Additional control over a start position, speed and volume of audio
playback
would be a useful feature in some applications.

Section 6.3.1 has an example of a volume control provided as a
platform-specific property. However, it also correctly states that
"platform-specific properties introduce incompatibilities".

VBWG Response: Accepted.

In section 6.3.1 of [5] we have clarified conformance behavior when
interpreter 
encounters properties it cannot process: it must (rather than should)
not thrown an error.unsupported.property and must (rather than should)
ignore the property. 


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).

VBWG Response: 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.

Received on Wednesday, 25 September 2002 10:15:31 UTC