W3C home > Mailing lists > Public > www-voice@w3.org > October to December 2004

Re: FW: VoiceXML 2.1 and PI issue

From: Dave Raggett <dsr@w3.org>
Date: Tue, 12 Oct 2004 20:40:59 +0100 (BST)
To: Brad Porter <brad@tellme.com>
Cc: MattO <matto@tellme.com>, Mike Bodell <bodell@tellme.com>, connolly@w3.org, www-voice@w3.org
Message-ID: <Pine.LNX.4.58.0410122028220.2854@holly>

Hash: SHA1

On re-reading Appendix E, I realize that I had missed an important
point, namely that the proposed PI is in the document referenced
by the data element, and that the referenced data document indicates
whether the referee is entitled to gain access to it. This 
invalidates my earlier analysis.

However, it still leaves open why a PI is the appropriate 
representation for the constraints on the referee. Going back to
the definition of <data/> in section 5:

  The <data> element allows a VoiceXML application to fetch 
  arbitrary XML data from a document server without transitioning 
  to a new VoiceXML document. The XML data fetched by the <data> 
  element is bound to ECMAScript through the named variable that 
  exposes a read-only subset of the W3C Document Object Model (DOM).

My understanding is that the PI in the referenced document is not
exposed in this subset of the DOM (see Appendix D) and hence is
invisible to the application through the bound ECMAScript variable.
If on the other hand the constraints on the referee were expressed
via attributes or elements, this would not be the case, and the
application would have access. Whether or not this matters is
unclear to me. Using a PI certainly simplifies how the application
accesses the bound data.

Dan, does this help in any way?


- -- Dave Raggett 
Version: GnuPG v1.2.4 (GNU/Linux)

Received on Tuesday, 12 October 2004 19:41:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:37 UTC