wiki:ShoppingBasket

-> http://proj.badc.rl.ac.uk/qesdi/wiki/

See  NDG Context Service for a generic proposal of how to implement this.

See also  Bryan's blog

QESDI Shopping Basket

We currently envisage a system with 4 major user-visible components:

  • the WMS client;
  • a data download page;
  • a shopping basket;
  • search and discovery service.

The idea of the shopping basket is to provide the user with a means of identifying the WMS endpoints he is interested in, and then passing the list to the WMS client. This needs to be separated from the WMS client, I think, in order to prevent the latter from suffering mission creep and to avoid having to cram too much into the limited space on one web page.

Making this split raises the issue of how the 3 components should interact, and how they might ultimately interact with the IS-ENES, BADC and NDG discocery services in future devlopments, so I wanted to check whether there were any existing plans.

There a MOLES catalogue entry for a WMS -- with the current QESDI UI, a WMS can be viewed by pasting the URL into a text box -- functional, but not entirely user friendly. One option is to add a link which launches a WMS UI pointing to the WMS. This has the drawback that it may not be clear to the user how to combine several different WMSs in one UI. A solution, I think, is to have a shopping basket with an "add WMS" action which can be triggered by a URL. E.g. qesdi.ac.uk/wms_sb/addToBasket=<wms url>. This URL could be entered in the MOLES catalogue as the "WMS" URL, and the rest would follow. It might be cleaner to keep the MOLES WMS item for the WMS itself, and add a "WMS viewer" item to the properties of a data entity. To work sensibly, the "add WMS" URL would have to be associated with an HTML target, so that any existing shopping basket session is updated. It may also require some SessionManagement.

The QESDI "discovery service" may be no more than a list of 30 to 40 datasets, with links to more detailed descriptions. For IS-ENES a more structured approach will be necessary, but may be developed elsewhere -- hence the need for a clean separation.

Use case

User has a shopping basket page open in a browser (SBUI, if we follow the model of having a WMC). In another window he discovers a MOLES catalogue record with an interesting WMS -- he clicks on a link which adds the WMS to his shopping basket and, if possible, updates his SBUI.

Spascoe comments

Modelling the shopping-basked concept as a separate REST service is a good idea. This service should serve it's state as Web Map Context documents, using WMC extensions where necessary -- The COWS code already has some support for WMC. As Martin describes, the service should allow adding of WMS endpoints as well as removing.

The WMS client could save it's state to the WMC service to allow users to store which layers they were viewing.

Several refinements could be made to make the service more RESTful. Each user could have their WMC available at a separate URL (e.g.  http://qesdi.ac.uk/spascoe/wmc). The URL  http://qesdi/ac/uk/wmc could relocate to the authenticated user's WMC URL. Possible RESTful requests might be:

HTTP METHODRequest body typeResponse typeDescription
GET n/a WMC XML Retrieve context
POST WMS URL WMC XML Add WMS to context
PUT WMC XML WMC XML Set WMC
DELETE WMS URL WMC XML Remove WMS from context

Context User Interface

The Context UI will appear to the user as a web-page displaying the items they have chosen, options to interact with the WMC server (i.e. a "delete item" button), an option to paste in a WMS URL which the user has found elsewhere, and options to pass some or all of the WMS URLs and tags to a WMS UI. For data extraction there should also be links to the data extraction UI.

How does this relate to the use case above? When the catalogue service executes a put to the WMC server, it should also open (execute a GET to) the Context UI, with the html attribute TARGET set to a value associated with the Context UI -- that is, ideally two independent catalogues should know and use the same target value, so they return the user to the same view of his context. So the cataloue service needs to know at least four things: the WMC service URL, data extraction UI, the Context UI URl, and the Context UI preferred target. There may be other services. Finally (or firstly?) the catalogue service needs to obtain security clearance to update the context. This could be done through the Context UI: i.e. open up/refresh the UI URL and let the UI deal with security issues. By this approach, the catalogue service does not need to deal with the security issues directly.

Is there a better way of doing this, rather than relying on the TARGET attribute? E.g. just make the Context UI refresh every second?

The kind of context required could be:

<item shortname="HADCM3-SRESA1" name="HADCMS, scenario SRESA1">

<longname>.....</longname> <description> ... </decsription> <servicelist>

<service type=".." url="..." viewer="..."/>

</servicelist>

</item>

The Context UI could be written in javascript to run on the browser, or it could be a server side dynamic page. The latter would have the advantage of greater flexibility regarding session management and security. The former might give a cleaner user experience.