Technical Standards for the JISC IE (part 1)

One of the key conclusions emerging from our ongoing consultation with some of those who have been involved with the JISC Information Environment (JISC IE) since its early days is that the emphasis on interoperability through open standards was one of the key drivers which gave the programme direction and momentum. Giving focus to this emphasis on open standards was a web document, JISC Information Environment Technical Standards, which introduced itself thus:

This document provides a list of the key standards and protocols that make up the JISC IE technical architecture. This document is intended primarily for developers, in order to provide them with a single point of reference to the main technologies that they should be using when working in the context of the JISC IE.

These standards are intended to apply to all JISC IE service components listed in the JISC IE Glossary (portals, brokers, aggregators, content providers, subject gateways, authentication/authorisation services, service registries, user-preferences services, OpenURL resolvers, institutional profile services, metadata schema registries, terminology services or other shared infrastructure services).

It has been suggested by more than one of those with whom we have consulted that this document was the most important of the several documents developed by UKOLN (primarily by Andy Powell) to technically inform what was then designated the JISC Information Environment Architecture. It gave those developing services in the JISC IE a touchstone, allowing them to validate that their work was in accordance with one of its over-arching principles. During our consultations, we have heard more than once that this document was more important than the perhaps more widely recognisable Technical Architecture diagram.

The document borrows the Internet Engineering Task Force (IETF) convention of using the words must, should and may (in a bold typeface) in a particular way to convey a more precise indication of the strength of recommendation or requirement being articulated. Nevertheless it has, for some, been unclear whether or not this document was intended to mandate or to advise on the use of technical standards in the JISC IE. Although the IETF convention was not applied to the document’s introduction, it seems reasonable to take the line that when the author said:

This document is intended primarily for developers, in order to provide them with a single point of reference to the main technologies that they should be using when working in the context of the JISC IE.

we might reasonably interpret that use of the word ‘should’ in the IETF sense, to mean:

should – indicates that there may exist valid reasons not to treat this point of guidance as an absolute requirement, but the full implications should be understood and the case carefully weighed before it is disregarded

So, it is reasonable to argue that the JISC IE was, at a technical level, based on an identification of appropriate technical standards. We will assume that the provision & maintenance of such a document is still useful which means that, in looking forward to the future, two questions present themselves:

1. Should the document be ‘prescriptive’ or ‘descriptive’?
2. Which standards are relevant to the JISC IE today?

For this post, we’ll address the first of these questions – a second post, which will appear in a few days, will address the other.

Prescriptive or descriptive?

Should our ongoing identification and documentation of the next iteration of what we are now calling the JISC IE Technical Foundations take a prescriptive (‘must’) or descriptive (‘may’) approach to its treatment of technical standards?

It has been suggested that the original, somewhat prescriptive approach had the effect of embedding the belief of the importance of shared, open standards for interoperability into the culture of those developing services for the JISC IE. But it has also been suggested that this cultural acceptance has now been achieved and that developers can be trusted to assume the need for interoperability and, consequently, be given freedom to innovate where appropriate.

Is the importance of open standards now so widely accepted that we can assume that developers will make sensible choices, balancing the need for interoperability with the desire to innovate?