- From: Brad Porter <brad@tellme.com>
- Date: Wed, 17 Jan 2007 13:05:39 -0800
- To: public-appformats@w3.org
I haven't integrated this into the document as I believe we need some section restructuring, but I want to wait for Anne's changes before incorporating them. --Brad 3.1 Description of Browser Sandbox for XML "read" The processing instruction is designed explicitly to enable extending the sandbox for access to XML content for "read" access. Web browsers strive to make it "safe" to run any application fetched from the Internet. In order to safely run untrusted code, the web browser tightly controls which resources the web page is allowed to access. In this way, the browser creates a safe "sandbox" in which the application can run. One of the capabilities that web browsers allow is for one site to create a hyperlink to another site. Similarly, a web browser allows a site to display an image from another site. For instance, an HTML page from www.example.com may display an image hosted by www.w3.org. This interaction is considered "safe" because the contents of that image are displayed to the user, but are not exposed to example.com. In order to make the experience safe for the end user, web browsers must tightly control access to data. Web pages or XML documents often contain sensitive information such as account balances or personal correspondences or corporate financial information. Consequently, the browser must prevent an example.com application from making a request from your browser that would allow it to "read" your sensitive information. Because the web browser can not tell which web pages or XML documents contain sensitive information and which do not, the browser sandbox by default restricts all "read" requests. An application in example.com can not load or inspect the contents of data from any other document. Some browsers make an exception if the "read" request is for data from the same host or domain. For instance, a web page from www.example.com could request to read another XML document hosted on documents.example.com. In HTML browsers, the Javascript function XMLHttpRequest allows this type of XML read access. VoiceXML 2.1 browsers implement this functionality with an element named <data/>. The restriction on XML "read" is very strict. There are cases where an application would like to "read" data from another XML document on the internet without these restrictions. For instance, a car reservation web site may want to request your trip itinerary data from an affiliated airline reservation website to streamline making your car reservation. An online retail store may want to read information from a shipping company to give you information on when your order will arrive. The access-control header allows an XML data document to declare that it is safe for the web browser to allow another site to read this data. By specifying an access control header that "allows" example.com to read, that particular XML document is saying "Yes, it is safe to allow an example.com application to read this data." 3.2 Definition of XML "read" XML read request: A request made by an application to load an XML document in a manner that allows the application to inspect the contents of that XML document. Upon inspection of the contents, the application can perform any other allowed operation using that data such as presenting it to the user, performing calculations or making decisions based on that data, copying the data into another data object, and submitting it back to its own website.
Received on Wednesday, 17 January 2007 21:05:55 UTC