Brad Porter, <brad@tellme.com>
27 April, 2007
<data/> element allows VoiceXML application to access an XML file and use the DOM to retrieve the contents
Beyond the standard separation of data and presentation, this allows:
Problem: Many clients running in one shared network. (e.g. E*TRADE, Merrill Lynch, United Health Group, Fedex, American Airlines). Must enforce browser sandboxing.
Problem: Allowing access only back to the same domain is overly restrictive. www.fedex.com may want to share package tracking data with www.aa.com. www.fandango.com may hosting partner to access to theatre, showtimes, and ticket purchase XML APIs.
XML data itself can specify who has the rights to the data using an access-control processing instruction.
Existing sandbox approach:
Immediately rejecting the request if the target domain differs
from the application domain
New sandbox approach:
Fetch the target data. If access-control processing instruction
allows application domain access to the data, provide it. Otherwise reject the request.
VoiceXML example (http://voice.airline.com/baggage_tracking.vxml):
<vxml version="2.1"> <var name="package_id" expr="'112112332'"/> <data name="package_record" src="http://shipper.com/track_package" namelist="package_id"/> <prompt> This package will arrive on <say-as type="date:mdy"> <value expr="package_id.getElementsByTagName('expectedarrival')[0].getAttribute('date')"/> </say-as> </prompt> </vxml>
Data Example (http://shipper.com/track_package?package_id=112112332):
<?access-control allow="shipper.com airline.com"?> <package id="112112332"> <origin zipcode="13152"/> <destination zipcode="94404"/> <expectedarrival date="07/14/2007"/> </package>
Removed from VoiceXML 2.1 specification
Published as a NOTE instead to document a shared practice amongst Voice Browser vendors
As I said, beyond the buzzwords we can notice two trends:
a) more sophisticated applications running in the browser sandbox
b) new data and combinations of this data is appearing on the web.
Source: Didier PH Martin http://www.stylusstudio.com/xmldev/200508/post50220.html
When the XMLHttpRequest object operates within a browser,
it adopts the same-domain security policies of typical JavaScript
activity (sharing the same "sandbox," as it were). This has some
important implications...
...the domain of the URL request destination must be the same as
the one that serves up the page containing the script. This means,
unfortunately, that client-side scripts cannot fetch web service data
from other sources, and blend that data into a page.
Source: Apple Developer Connection http://developer.apple.com/internet/webcontent/xmlhttpreq.html
But the kind of AJAX examples that you don't see very often (are there any?) are ones that access third-party web services, such as those from Amazon, Yahoo, Google, and eBay. ... browsers impose a significant security restriction on the use of XMLHttpRequest... you aren't allowed to make XMLHttpRequests to any server except the server where your web page came from...
...there are gruesome hacks, that can bring the splendor of seamless cross-browser XMLHttpRequests to your developer palette. The three methods currently in vogue are:
Source: O'Reilly xml.com "Fixing AJAX: XMLHttpRequest Considered Harmful" http://www.xml.com/pub/a/2005/11/09/fixing-ajax-xmlhttprequest-considered-harmful.html?CMP=OTC-TY3388567169