Re: Not waiting on browser manufacturers for RDFa 1.1

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