VBWG official response to last call issue

Dear James,

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 10th, 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
10th, 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/2004OctDec/0014.html you
raised the following issue which was registered as change request R105. Our
response is given inline:

"I have a question. Please can you explain why the mechanism defined in "7.
Recording User Utterances While Attempting Recognition" returns a binary
waveform rather than a URL that points to the waveform? Is it to avoid
firewall issues?

This is in the context of MRCP 2 where a mechanism is provided to save
waveforms on a recognition by recognition basis (using the save_waveform
parameter). The waveforms are saved on the rec server. The MRCP recognition
result does not return the binary waveform to the browser, but a URL that
points to it. This would appear to be more efficient."

VBWG Response: Rejected

By using the term 'reference', the specification of the utterance recording
feature in VoiceXML 2.1, similar to that of the record feature in VoiceXML
2.0 [4], is careful to leave the format of the value of the recording
variable and the physical location of the recording as an implementation
detail of the platform. The only requirements are:
  1) The browser must be able to play the recording to the user and,
  2) The browser must be able to submit the binary recording to a document
server 
as indicated in the following excerpt from [4]:

"Note that how this variable is implemented may vary between platforms
(although all platforms must support its behaviour in <audio> and <submit>
as described in this specification)."

These requirements help to enforce a separation between the client, the
voice browser in this case, and the server, an architectural principle to
which the group believes strongly that all Web-based specifications should
adhere.

[4] http://www.w3.org/TR/2004/REC-voicexml20-20040316/#dml2.3.6

Received on Thursday, 3 March 2005 23:43:12 UTC