- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Fri, 9 Jul 2010 14:46:43 +0100
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: RDFa WG <public-rdfa-wg@w3.org>
Hi Manu, Well...first we should be a little bit more precise about the problem domain. The issue is that if profiles are *only* defined using HTML+RDFa then you have this cross-domain issue. But as I said way back during the discussions on profile, if you allow profiles to be defined using JSON then you don't have this problem. I realise that everyone is drawn to the symmetry of using RDFa to define things that can be consumed by RDFa -- myself I've never been that bothered one way or the other -- but in this case it seems as if we gain nothing by neglecting to provide a JSON serialisation in our specifications. Also, requesting an HTML profile that contains RDFa, from a proxy that converts it to JSON-LD so that it can be consumed in a JavaScript RDFa parser is not exactly going the most direct route! Why not just go direct to source and get the JSON-LD? The world is using JSON for just about everything, and I think it's a little odd that we are wilfully ignoring that, and instead looking at the kinds of proxy hacks you describe (which as you say, have been around for years), to achieve a benefit that I've yet to hear elucidated. Regards, Mark On Fri, Jul 9, 2010 at 2:22 PM, Manu Sporny <msporny@digitalbazaar.com> wrote: > One of the biggest concerns that I (and many others) have had about RDFa > 1.1 is the requirement that external documents (RDFa Profiles) are > processed via Javascript. > > As we all know, cross-domain access in Javascript is difficult to do at > the moment. XSS protections in browsers are necessary. CORS doesn't have > high market penetration at this point in time. So, implementing a pure > Javascript RDFa 1.1 parser is impossible without a proxy RDFa Profile > fetching proxy. Implementing a reliable proxy is not possible without > using CORS and using CORS is not available in more than 98% of all > browsers. Whatever solution we use has to protect against XSS attacks. > > This has bothered me for some time and just last week while Shane and I > were talking about another implementation issue, a fairly robust > solution appeared: > > http://www.w3.org/2010/02/rdfa/wiki/rdfa-flash > > I don't know why it didn't hit me before because this is the solution > that we use in our company to do various different types of pure > Javascript, in-browser, peer-to-peer communication. > > You can use a combination of Flash and a policy file to do cross-origin > stuff safely. It's basically CORS, but implemented in Flash, which means > that 98% of all browsers support it. > > Yes, it is flash and it's proprietary, but this is a stop-gap solution > until the browser vendors integrate RDFa into the browser. Until that > day comes, we can use the cross-origin support built into Flash to > enable pure Javascript+Flash implementations of RDFa 1.1 Processors. > > We can protect against XSS attacks by having an RDFa Profile fetching > service out there that parses and caches RDFa profile triples and only > returns tokens in the RDFa Vocabulary specific to terms and prefixes. It > could return the data in JSON-LD[1] format. While this solution isn't > scalable, it would provide a stop-gap solution that would allow us to > demonstrate the power of RDFa using Javascript-only libraries. > > -- manu > > [1] http://rdfa.digitalbazaar.com/specs/source/json-ld/ > > -- > Manu Sporny (skype: msporny, twitter: manusporny) > President/CEO - Digital Bazaar, Inc. > blog: Myth Busting Web Stacks - PHP is Faster Than You Think > http://blog.digitalbazaar.com/2010/06/12/myth-busting-php/2/ > >
Received on Friday, 9 July 2010 13:47:19 UTC