Anyone interested in teh Warks Open Data XML files having access control allow all set (i.e. accessible via XMLHttpRequest from JavaScript)

[Dave Challender]

Hi,
   
Would anyone else like the Warks Open Data team to set access-control allow all (*) on all the XML files that comprise Warwickshire Open Data?
e.g. http://ws.warwickshire.gov.uk/libraries.xml

This can be done either in the header ( Access-Control-Allow-Origin: *
preferred option as means browser does not have to attempt to read the XML)
or can also be done as an element in the XML file.

As then, it should be possible to use JavaScript (in compliant browsers! .. some browsers are more wc3 compliant than others)
to dynamically grab the XML data - and so avoiding the need for "server side" code to read the xml (as from JavaScript you can apply XSL(T)
transforms and transform the XML data into a form to display to the user
e.g. maps showing the locations of libraries


This setting is required because (for fairly self evident security reasons) browsers normally disallow cross site calls unless the sites have the same
"origin", and so if you have XML data that you publish and want to make available to calling JavaScript via XMLHttpRequest then you have to jump
through hoops to do that.

For documentation see:

https://developer.mozilla.org/En/HTTP_Access_Controlhttps://developer.mozilla.org/En/Server-Side_Access_Control

The best part of this is that it removes the need for server side development and so people *without* access to a web server (with associated
development tools be they open source tools, Microsoft tools etc.) are not disenfranchised.
It allows someone to develop against the data using just JavaScript from their web browser... (obviously as ever it may take IE ages to catch up,
but you can already do proof of concept work with more standards compliant browsers such as Firefox at the moment).

Empowering for people to work on data mashups from a simple desktop system just using JavaScript in their browser.


Regards

Dave

[Owen Stephens]

Would offering the data via a JSONP response be an alternative? (I guess a bit more work for the Warks Open Data team though...)

Owen

Owen Stephens

Owen Stephens Consulting

Web: http://www.ostephens.com
Email: ow...@ostephens.com
Telephone: 0121 288 6936

[Steve Woodward]

Appreciate the thought Dave - this isn't something I would've thought
of because I've always done my fiddling server-side.

Off the top of my head, given a bit of time either the header setting
or data as JSONP will be do-able for data coming from
ws.warwickshire.gov.uk, not so sure about XML coming from our S3
bucket though.

Interested to know which you'd prefer out of the two.

cheers
Steve Woodward

analyst/programmer
Warwickshire County Council

On May 24, 5:40 pm, Owen Stephens <o...@ostephens.com> wrote:
> Would offering the data via a JSONP response be an alternative? (I guess a bit more work for the Warks Open Data team though...)
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web:http://www.ostephens.com

> Email: o...@ostephens.com

> Telephone: 0121 288 6936
>
> On 24 May 2010, at 15:49, Dave Challender wrote:
>
>
>
> > Hi,
>
> > Would anyone else like the Warks Open Data team to set access-control allow all (*) on all the XML files that comprise Warwickshire Open Data?

> > e.g.http://ws.warwickshire.gov.uk/libraries.xml

>
> > This can be done either in the header ( Access-Control-Allow-Origin: *
> > preferred option as means browser does not have to attempt to read the XML)
> > or can also be done as an element in the XML file.
>
> > As then, it should be possible to use JavaScript (in compliant browsers! .. some browsers are more wc3 compliant than others)
> > to dynamically grab the XML data - and so avoiding the need for "server side" code to read the xml (as from JavaScript you can apply XSL(T)
> > transforms and transform the XML data into a form to display to the user
> > e.g. maps showing the locations of libraries
>
> > This setting is required because (for fairly self evident security reasons) browsers normally disallow cross site calls unless the sites have the same
> > "origin", and so if you have XML data that you publish and want to make available to calling JavaScript via XMLHttpRequest then you have to jump
> > through hoops to do that.
>
> > For documentation see:
>

> >https://developer.mozilla.org/En/HTTP_Access_Controlhttps://developer...

[Dave Challender]

Having the XML accessible via the access control setting is the simplest option as should need little effort.
It also means, that any solutions which work on taking the XML and transforming it to give html (where the transform adds extra functionality e.g. producing a map with all the locations plotted) can benefit by avoiding duplication of effort.

e.g. Take my case (as I prefer server side code as I'm the sort of person who browses with JavaScript disabled by default!)
In my server side code I create an XSL(T) transform that  produces HTML from the Warks XML data (as many of the location based XML files have a very similar structure the transform covers multiple data sources).
If a JavaScript app can get the XML data, it can use the same transforms, saving a lot of work (assuming the XSL version & "dialect quirks" is compatible with the browser!).

.. Although I prefer server side work, none of the servers I do development on are www facing ... and so being able to do read of XML and transform it client side would be handy to demonstrate over the www.





Regards

Dave

[Jim Morton]

We've had a look at this and currently the Amazon storage that we are
using for the majority of our open data sets does not allow this level
of access, although there is a discussion here encouraging this
restriction to be sorted out:

http://developer.amazonwebservices.com/connect/message.jspa?messageID=167573

On 25 May, 09:48, Dave Challender <dave.challen...@gmail.com> wrote:
> Having the XML accessible via the access control setting is the simplest
> option as should need little effort.
> It also means, that any solutions which work on taking the XML and
> transforming it to give html (where the transform adds extra functionality
> e.g. producing a map with all the locations plotted) can benefit by avoiding
> duplication of effort.
>
> e.g. Take my case (as I prefer server side code as I'm the sort of person
> who browses with JavaScript disabled by default!)
> In my server side code I create an XSL(T) transform that  produces HTML from
> the Warks XML data (as many of the location based XML files have a very
> similar structure the transform covers multiple data sources).
> If a JavaScript app can get the XML data, it can use the same transforms,
> saving a lot of work (assuming the XSL version & "dialect quirks" is
> compatible with the browser!).
>
> .. Although I prefer server side work, none of the servers I do development
> on are www facing ... and so being able to do read of XML and transform it
> client side would be handy to demonstrate over the www.
>
> Regards
>
> Dave
>

[Dave Challender]

On 2 June 2010 13:56, Jim Morton <jimm...@warwickshire.gov.uk> wrote:

We've had a look at this and currently the Amazon storage that we are
using for the majority of our open data sets does not allow this level
of access, although there is a discussion here encouraging this
restriction to be sorted out:

http://developer.amazonwebservices.com/connect/message.jspa?messageID=167573

Thanks for investigating and reporting on the status of this -

Would have been nice if a client side only* solution was viable. Will have to keep half an eye on whether Amazon ever enhance their storage options.

* Including the ability of client side code to read the data on the fly (on the assumption data may change over time) - obviously still viable using a "local" copy of the xml data