VBWG official response to last call issues

Dear Robert,

The Voice Browser Working Group (VBWG) has almost finished resolving the
issues raised during the last call review of the 28 July 2004 working draft
of VoiceXML 2.1 [1]. Although your feedback was based on the First Working
Draft, the specification did not change radically, and we have evaluated
your requests against the LCWD [1]. Our apologies that it has taken so long
to respond.

Please indicate before March 7th, 2005 if you are satisfied with the VBWG's
resolutions, if you think there has been a misunderstanding, or if you wish
to register an objection. If you will be unable to respond before March 7th,
please let me know. The Director will appreciate a response whether or not
you agree with the resolutions.

Below you will find:

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

Thank you,

Matt Oshry
Chief Editor, VoiceXML 2.1

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

Per section 7.2 [2] of the 5th February 2004 Process Document, in order for
the VoiceXML 2.1 specification to advance to the next state (Candidate
Recommendation), the Working Group must "Formally address all issues raised
about the document since the previous step." 
Section 3.3.3 of the Process Document [3] sets expectations about what
constitutes a formal response:

  "In the context of this document, a group has formally addressed an issue 
  when it has sent a substantive response to the reviewer who raised the
issue. 
  A substantive response is expected to include rationale for decisions 
  (e.g., a technical explanation, a pointer to charter scope, or a pointer 
  to a requirements document). The adequacy of a response is measured
against 
  what a W3C reviewer would generally consider to be technically sound. 
  If a group believes that a reviewer's comments result from a
misunderstanding, 
  the group SHOULD seek clarification before reaching a decision."

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/2004/WD-voicexml21-20040728/
[2] http://www.w3.org/2004/02/Process-20040205/tr.html#transition-reqs
[3] http://www.w3.org/2004/02/Process-20040205/policies.html#formal-address

-----------------------------------------------
2) Issues you raised and responses
-----------------------------------------------
In http://lists.w3.org/Archives/Public/www-voice/2004AprJun/0025.html you
raised the following issue which was registered as change requests R66 and
R67 Our response is given inline:

"Firstly I would like to say that these small changes address some very
useful additions to VoiceXML.

I am slightly disappointed that the support for <mark> does not go further
and support
client side audio control. application.lastresult$.marktime will support
very simple audio control
by sending the marktime as a url parameter in an audio request and having
the application server
apply offsets to the original audio file. However, there are two important
cases where this will not work:
- TTS prompts
- where several audio files have been queued together  (putting a mark on
every prompt in the queue and
  restarting the prompt queue from the last mark would be very awkward
solution)
I believe that several voice browsers already support greater functionality
via non-standard extensions
and it seems a pity that these could not be standardised in VoiceXML 2.1."

VBWG Response: Deferred

Client-side audio control has been deferred for a future version of
VoiceXML.

"I also think Teemu Tingander raises a good question about the naming of the
expr attributes
for <script> and <grammar>. (Logically the expr attributes on <audio>,
<next> and <submit>
should also be srcexpr. <subdialog> already uses srcexpr, but expr in this
case is an asignment 
of the subdialog variable, not a definition of the subdialog fetch.) Even if
there is no immediate
intention to support dynamic grammars via <grammar expr="..."/> where expr
evaluates to an actual grammar, it seems a mistake to close off that
possibility in future."

VBWG Response: Accepted

The working group has accepted the feedback from you and others in the
community including Teemu that "srcexpr" is a more appropriate name for the
dynamically evaluated attribute. This feedback was incorporated into the
Last Call Working Draft [1].

Received on Monday, 28 February 2005 22:47:39 UTC