Ivan Herman wrote:
On 2010-1-12 16:13 , Manu Sporny wrote:
Ivan Herman wrote:
It does put an extra load on implementation that is non negligible.
Yes, that's very true. Remote retrieval of vocabulary documents makes it
impossible to do a Javascript implementation unless there is a new
browser feature added (for retrieving plain text @vocab documents). For
example:
var vocab = document.getVocabulary("http://example.org/vocab";);
The http://example.org/vocab document would have to exist in the current
document in a @vocab attribute in order for the browser to allow
retrieving it. We may want to consider adding this requirement to the
RDFa API document.
That is a tall order. I am not a JS expert but isn't it correct that
this restrictions is deeply rooted in the browser environment?
If I'm understanding the discussion correctly, then the problem is that
browser security is based on the same-origin policy, which means scripts
running on a page generally can't access data from a different origin
(where "origin" is basically domain+port+scheme). So a script that's
used on http://whatever.example/ can't access data from
http://example.org/vocab (because that would allow the first site to
access private data on the user's intranet, or private data that other
sites associate with the user via cookies).
CORS (http://dev.w3.org/2006/waf/access-control/) allows servers to
relax that restriction, so example.org could be configured to allow
access from anyone, in which case it could be read with XMLHttpRequest
(in Firefox 3.5+ and Safari 4+; and with XDomainRequest in IE8+).
I'd expect an API like getVocabulary that doesn't use CORS and ignores
the same-origin policy would be rejected as insecure, since it can be
used to reveal information that would otherwise be inaccessible to scripts.
--
Philip Taylor
pj...@cam.ac.uk
