W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2005

VBWG official response to last call issues

From: MattO <matto@tellme.com>
Date: Mon, 28 Feb 2005 13:09:31 -0800
To: "'Teemu Tingander'" <Teemu.Tingander@tecnomen.fi>
Cc: <www-voice@w3.org>
Message-ID: <001a01c51dd9$cca4d370$396d8243@sea.tellme.com>

Dear Teemu,

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/2004JanMar/0052.html you
raised the following issue which was registered as change requests R62
through R65 Our response is given inline:

"Some comments to VoiceXML 2.1 Working Draft 23 March 2004 and some more
VoiceXML 2.0. 

As a general comment for <data> elements DOM mapping; I don't see why we
should add more complex programming capabilities into voicexml and once
again make it possible to move the complex application logic into UI side !"

VBWG Response: Rejected

The data element allows a clean separation of dynamic data from static
presentation markup. A benefit of this approach is the ability for multiple
applications targeted at one or more modes of interaction to consume data
produced via a well-defined URL API. Another benefit is the ability for
browsers to cache the presentation markup. Irrespective of this position,
the VoiceXML 2.1 specification states the following:

'If an implementation does not support DOM, the name attribute must not be
set, 
and any retrieved content must be ignored by the interpreter.'

This implies that the data element can also be used purely for its
non-transitional "send" capabilities (HTTP GET or POST).

"Chapter 2.  Referencing Grammars Dynamically.

I propose the use of attribute srcexpr in <grammar> element. This will leave
the expr attribute to be used to evaluate the "grammar" content from
javascript content etc. Especially this is handy when data is introduced !"

VBWG Response: Accepted

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

"Chapter 3 Referencing Scripts Dynamically'

Once again I propose attribute srcexpr just to make difference between value
for element and 'value that evaluaes to attribute value'.."

VBWG Response: Accepted

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

"Chapter 3 Using <data> to Fetch XML Without Requiring a Dialog Transition

Once again I propose attribute srcexpr. Expr attribute could be used as it
is in var. As data is clearly a some kind of extension of <var> element."

VBWG Response: Accepted

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

"Using DOM in <data> is far to complex. I suggest of finding some more
simplified structure for returned data. We could use a simple pattern like..

     <data name='temp' src....
  and as returned:

  <data>
    <property name='a' expr='1'>
    <property name='b' expr='-1'>
    <property name='c[0]' expr="'temp'">
    <property name='c[1]' expr="'tester'">
  </data>

This could then be mapped into javascript:
    temp {
            a = 1;
            b = -1;
            c  = {
                [0] = 'temp'
                [1] = 'tester'
            }
     } 

  And so on..  its easy to use it in this way.. Somehow this could be made
in VXML 2.0  with script element too..
  Or even use that same mapping we use in SSML to field values
  And some more changes that I formerly proposed.. Still waiting for answers
or at least comments.."

VBWG Response: Rejected

The Voice Browser working group performed a rigorous study of commonly
implemented features and their associated use cases.
Three clear needs arose from that study: 
  1) The ability to perform a non-transitional HTTP fetch.
  2) The ability to access data from back-end data sources.
  3) The ability to manipulate that data using a standard object model.
Several existing implementations showed that the reflection of XML data
through the W3C DOM was a natural solution to solve these problems.

"And some more changes that I formerly proposed.. Still waiting for answers
or at least comments.."

We have omitted the text from your original message regarding clarifications
on VoiceXML 2.0 as the purpose of this communication is solely to address
issues with the set of features described in VoiceXML 2.1. Please send
issues and clarifications regarding VoiceXML 2.0 as an independent
correspondence to the public mailing list at www-voice@w3.org. These will be
evaluated and, if appropriate, addressed as errata to VoiceXML 2.0 [4].

[4] http://www.w3.org/2004/03/voicexml20-errata.html
Received on Monday, 28 February 2005 21:10:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:00 GMT