Re: RDFa Vocabularies

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
pjt47@cam.ac.uk

Received on Tuesday, 12 January 2010 17:03:37 UTC