Setting a direction for development

Feedback is starting to come in on the v0d consultation draft of the XCRI curriculum schema. Respondents have acknowledged the complexity of the domain space and stated that their first impressions of the schema are good. Some refactoring is expected as a result of the consultation, which is allowed for in the project plan. It is apparent that institutions will be in a better position to assess the schema when it is being demonstrated through working examples, particularly web services that return realistic curriculum content. With that in mind, various options for a technical prototype have been considered. Most promising for a quick-win is a REST web service for retrieving curriculum content in response to XPath queries.

Although nothing directly curriculum-related was apparent, research higlighted Kimbro Staken's Syncato XML-based blog as particularly interesting. Written using Python and Sleepycat Berkley DB XML, Syncato adopts a neat approach of URLs made up of two parts: listener and xpath_expression

This REST approach provides a powerful and flexible interface for extracting XML content, which can then be passed through XSLT for display. This article on XML.com illustrates how XPath extracts desired content through (escaped) URLs such as:
http://www.xmldatabases.org/WK/blog/item//songlist[song/title='Pride%20And%20Joy']

Kimbro Staken's Syncato listener also receives a querystring parameter that is used to specify a transform to apply (in this case to produce HTML):
http://www.xmldatabases.org/WK/blog/item[//songlist/song/title='Pride%20And%20Joy']?t=item

A wet Sunday evening, lousy telly and the notion of XCRI as displacement activity created the incentive to develop the idea a little further:

If the XPath query went into the URL, is there a similarly neat way to handle error messages?

Scott: how about defining specific meanings for existing HTTP codes (as in Osmotic's REST tutorial)?

Neat. According to the HTTP/1.1 definitions we'd have:

Permissions, permissions ... so what options have we got for handling security

Scott: it really boils down to the following:

1. the favourite REST security method for consumer-oriented services is to use TLS(HTTPS) + HTTP Basic for username and password
2. for system-to-system services a better security method is to use TLS with client authorization - basically this is the same as normal TLS except BOTH the requester and the responder must supply certificates that the other accepts (normal TLS only requires that the client accepts the certificate of the service)
3. an API key is passed as a mandatory parameter on all requests - as in Google and Yahoo. This is generally to prevent excessive use by particular parties rather than to restrict access per se.

Our conclusion was that although most of the use cases for a curriculum web service would be predicated on wide availability of content, option 3 could have attractions for managing demand/bandwidth. So that's a neat URL formulation and two parameters identified so far: apiKey and xslt. We know that XPath could return any elements from our XML schema, so the response structure would be efc:any. We'll have a WSDL yet!

Now ... if only there were an XML database knocking around that we could prototype this on ...

Mark: What about Apache Xindice?

Described as a native XML database, Xindice uses XPath for its query language and XML:DB XUpdate for its update language. It also provides an implementation of the XML:DB API for Java development and it is possible to access Xindice from other languages using built-in XML-RPC API. Maybe it's a sign of age to have performance alarm bells go off at the words native XML database, but Xindice deserves some investigation for proof of concept for the XCRI REST web service dreamed up one wet Sunday evening. We'll definitely be consulting the XCRI partners to find out more, as a little digging reveals that Selwyn used it in 2003 for the JISC-funded ioNode/SHELL project.

So would a REST XPath curriculum web service be a useful prototype?

Paul: because XCRI centres around what we might call addressable resources, it fits REST quite neatly. The big challenges are with authoring but that'll need to be cracked in the future. For now, XPath queries would allow us to serve fragments of individual documents, or aggregated fragments of documents, e.g. 'get me all of the assessment component elements for all business school units'. This opens up possibilities for fine-grained requests which:

• might be more efficient in terms of bandwith
• allows better logging of requests which could become a rich source of business intelligence.
  For example, 'how many of our students are interested only in courses which are taught on this campus', or 'which subjects are not being queried by potential applicants'

Bottom line: we think we have an idea worth prototyping .. watch this space!

Talking information models with COVARM and SUNIWE

Curriculum touches on a number of other JISC-funded projects and XCRI has enjoyed its dialogue with regional pilots: Pathways4Progression and L4ALL, and its close links with fellow reference models: COVARM and FREMA. The prospect of a joint meeting with Balbir Barn and Hillary Dexter of COVARM and Mark Stiles of SUNIWE could not be missed.

The meeting, kindly hosted by Manchester University's Distributed Learning Centre, provided each of the projects with the chance to update the others on progress and to highlight possible synergies and opportunities for future collaboration. It created an ideal opportunity to compare XCRI's emerging schema with information models built up through the two projects, and initial discussions:

• raised an area for future development of the XCRI schema surrounding Mark Stiles' work on just-in-time assembly of learning resources, in particular the mapping of activities to curriculum components and then assigning assets and ascribing a purpose to each activity
• demonstrated strong support for XCRI's separation of curriculum component and offering, and allowing institutions to type and assemble curriculum components in a way that fitted their customs and practice (rather than hard-coding distinctions between programme and module)
• identified InfoPath as a smart, native XML forms technology that was particularly interesting to all projects and deserved further investigation
• highlighted serious conceptual problems translating between XML and UML models, which hindered progress in sharing experience

COVARM and XCRI agreed to meet on November 21 to review the information models that had emerged and to partition development effort with a view to facilitating re-use of web services.

In preparation for that meeting and taking on-board some of the initial feedback on the v0d schema, a UML class diagram is being produced to illustrate the XCRI XSD. Stereotypes of <<elm>> <<attr>> are used to highlight elements and attributes, respectively. The latest version can be downloaded by clicking the reduced image below:

Please note that this version begins to respond to comments made by Alan Paull of UCAS about overlap between academic entry critieria (now expressed in a structure under prerequisite) and administrative arrangements/broad policy for interviews etc (to appear under an admission element). The prerequisite structure, which provides for meeting either <all> or one from a <choice> of specified requirements is introduced to stimulate debate about modelling entry requirements/prerequisites for enroling on a curriculum component. Conversations with SUNIWE emphasised the importance for providing pathways advice of modelling course prerequisites in a manner that could be compared with data available on a learner's achievements to date.