Getting Technical

One of the main outputs of the Course Data projects will be an XCRI-CAP feed, an externally accessible source of the courses data covered by the project. Our first newsletter covered expectations in respect of where to locate the feed and licensing arrangements. This brief article addresses the type of feed.

The Course Data Programme does not prescribe any specific technology for the feed. The feed can be a RESTful service, a SOAP or other web service, a simple XML file accessible via an HTTP request, or any other similar technology. The primary requirement here is that the data can be obtained automatically by another computer system using the internet.

For consistency across the projects, we would expect feeds to conform to the XCRI-CAP version 1.2 information model and to be compliant with or directly mapable to the XCRI-CAP 1.2 W3C binding.

The details of the XCRI-CAP 1.2 information model are given in the XCRI wiki.

The XCRI-CAP 1.2 W3C binding re-uses elements from other linked schemas, all of which are available via the XCRI wiki or directly from the Knowledge Base.

You can find out about the technicalities of XCRI-CAP from several sources. As a starting point, refer to the Technical Implementation section of the Knowledge Base. This web page has links to examples and code, tools, case studies and other resources.

Setting up your XCRI-CAP feed

Static file

A static file approach requires your systems and processes to make and publish a file containing your course catalog. This means that the data is only as up-to-date as your file maintenance permits. Updating of the file is best done on a regular basis, dependent on how frequently the information changes. The creation and publication of the file can be automated. A static file can be made available via a web service or directly published on a web page for access by a browser or for download by a software application.

Dynamic Web Service

Alternatively you could set up your system to output the data via a web service fed from a database, so that your course catalog is built afresh whenever the service is used.  This means that when users or systems connect to your web service, they will receive a copy of the live or current version of your course data. The web service enables you to exert some control over access to the data, if required, for example by including security, tracking or error checking.