Re: Non-XHTML host languages for RDFa

Hi Toby,

On Tue, Dec 1, 2009 at 9:16 AM, Toby Inkster <tai@g5n.co.uk> wrote:
> On Tue, 2009-12-01 at 08:48 +0000, Mark Birbeck wrote:
>> Right...but as I say, a JavaScript parser running in a browser would
>> not be able to retrieve those RDFa documents, if they were in a
>> different domain to the main document.
>>
>> So even if we do support that, I think we need to do it in a way that
>> also supports a JSON solution.
>
> XHR requests are domain-restricted. This is the case whether the
> profiles are in XML, XHTML or plain text. JSON doesn't change that.

Yes -- I know.


> So called "JSON-P" (which is actually Javascript, not JSON) provides a
> workaround, but also opens a gaping security hole as it allows the
> server you're reading from to inject arbitrary Javascript code into your
> document. If your document contains any private data (e.g. you're using
> RDFa on pages containing your company's internal data on a page that's
> behind a corporate firewall) then a malevolent JSON-P profile could be
> used to steal that data.

As with anything, you would use profiles from people and places you trust.

Any unease someone has about using a profile from a Google server (for
example), would apply equally to using Google Maps in their pages. In
fact, the whole system of Google providing a CDN for JS libraries like
jQuery and YUI, is equally suspect -- if you trust their CDN, trust
their profiles...otherwise don't use either. :)

But anyway, the main point I'm getting at is that we don't want to
limit the technological choice for creating token lists.

Many people have mentioned that it would be nice to use RDFa to
describe the tokens, and whilst there is obviously an attractive
symmetry about doing that, I'm flagging up that if that was the /only/
solution on offer, it would be difficult for browsers to obtain the
data, without going via some kind of proxy.

On the other hand, if a number of methods are supported, we have more
flexibility.

This would imply coming up with a way of defining tokens that is
syntax-independent -- perhaps using RDF.

In short, I'm suggesting that we stick with discussing the general
solution, before alighting on a particular delivery mechanism.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Tuesday, 1 December 2009 09:48:47 UTC