- 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
-----BEGIN PGP SIGNED MESSAGE----- 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? Regards, - -- Dave Raggett -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBbDNRb3AdEmxAsUsRAouKAJ9lT4Es71Y6R2x1H+PFxUHIxK3HTgCeMaLu YbnV6nxK1NDnsnqJbQFLVKE= =g3oe -----END PGP SIGNATURE-----
Received on Tuesday, 12 October 2004 19:41:00 UTC