Impending web-arch issue?

All,

I've been doing a bit of prototyping and planning over how read write 
web of data / web applications may work in the (near) future and run in 
to a potential bump in the road - unsure where else to turn with this 
one, hence mentioning here.

Setup:

I've implemented Linked Data, where all data is saved in static RDF 
documents, accessible via deferenceable URIs, thus access is granular 
and HTTP/cache friendly.

On top of that I've implemented Web Access Control using ACF/ACL as 
described on ESW wiki and by TimBL in the CloudStorage Design Issue.

User Identification and authentication is handled via webid / FOAF+SSL.

Effectively this setup has given me a decentralised data tier mounted on 
the web where HTTP(S) is the interface via GET/PUT/DELETE etc (with 
aditions of exposing additional update methods via SPARQL Update or 
WebDav, and utilizing the Link header for WAC).

Next up I started to make a "web application" to view/crud the data, 
after going through the options I came out with HTML5+JS as being the 
perfect candidate, namely because it would:
- make the application(s) available widely, almost universally
- allow the application to be delivered over HTTP
- run in the browser thus making use of the existing client side cache
- make use of a native HTTP client and access to the full web of data
- nativly provide all the UI elements I could need /CSS/Accessibility
- many more reasons.

Also it's critical to note that (afaik) to use the Data Tier / web of 
data, then the UA/client application has to interact directly with the 
data and not through traditional server side applications, primarily due 
to WebAccessControl and FOAF+SSL (add in any middle apps and the client 
side certificate for auth* get's lost).

Plan was to port over RDFLib/ARC to JS, implement in memory SPARQL on 
the client side, and have a nice client side framework for parsing RDF, 
editing via forms, then rebuilding back in to RDF and updating via 
PUT/SPARUL/WebDav - thus building on the work of Jeni Tennison's 
RDFQuery, Benji's Data Wiki and in many ways the original User Agents 
with editing capabilities / Amaya etc. and effectively creating 
Tabulator in JS.


Problem
However, here's the problem, over the past few years of the Web "same 
origin policies" and the sandboxes have been introduced to combat cross 
site scripting, which effectively means that any application that could 
be made in JS is limited to the confines of the same domain, and often 
worse - thus since this is inherited, all the aforementioned is rendered 
useless and unusable before one can even start proto-typing it.

Short version, I can't make a client side web application that runs in a 
web browser and uses data from the web, even something as simple as an 
ACL editor or a FOAF Profile viewer.

Thus far the only thing I can see that comes any where near to 
addressing is the work in progress Cross-Origin Resource Sharing [1] but 
afaik it's only implemented in the newest browsers + the vast majority 
of resources on the web don't have these headers set so again the 
application wouldn't be able to access most data - rendering any apps 
made very limited and virtually useless - which imho is a huge shame 
since all the peices needed are ready and waiting on billions(?) of 
machines.

I may be going down the wrong track here, but it feels like the correct 
path to persue, the next logical step for read write web, and is fully 
supported even by old browsers like ie6, all apart from this XSS issue.

side: I've not looked in to FOAF+SSL through a Proxy, but it may be an 
option to mount a proxy on the same domain as the application and 
utilize it(?) - not ideal, no idea if it could work [head scratching]

Any input, ideas, places to turn?

[1] http://www.w3.org/TR/cors/

Best,

Nathan

Received on Monday, 10 May 2010 08:11:15 UTC