I'll try to get my CVS access working this week and apply the edits you
mention before next Wednesday's review.
--Brad
Anne van Kesteren wrote:
On Wed, 17 Jan 2007 22:05:39 +0100, Brad Porter <[EMAIL PROTECTED]> wrote:
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.
Hi, it's not entirely clear to me whether this needs to become the
introduction or another separate section. I think it would be good to
integrate these two proposed sections into one and make them become
the introduction.
Also, I was wondering if there was a non-XML specific version of this
text as that's what should be in the document.
--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.
--Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
