This page is for printing outthe briefing papers in the areas of standards. Note that some of the internal links may not work.

What Are Open Standards?

Background

The use of open standards can help provide interoperability and maximise access to resources and services. However this raises two questions: "Why open standards?" and "What are open standards?".

Why Open Standards?

Open standards can provide several benefits:

Application Independence: To ensure that access to resources is not dependent on a single application.
Platform Independence: To ensure that access to resources is not restricted to particular hardware platforms.
Long-term Access: To ensure that quality scholarly resources can be preserved and accessed over a long time frame.
Architectural Integrity: To ensure that the architectural framework for IT developments is robust and can be further developed in the future.

What Are Open Standards?

The term "open standards" is ambiguous. As described in Wikipedia "There is no single definition and interpretations vary with usage" [1]. The EU's definition is [2]:

The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty-free basis.
There are no constraints on the re-use of the standard.

Some examples of recognised open standards bodies are given in Table 1.

**Table 1: Examples Of Independent Standards Organisations**
Standards Body	Comments
W3C	World Wide Web Consortium (W3C). Responsible for the development of Web standards (recommendations). See <http://www.w3.org/TR/>. Relevant standards include HTML, XML, CSS, SMIL, SVG, etc.
IETF	Internet Engineering Task Force (IETF). Responsible for the development of Internet standards (known as IETF RFCs). See list of IETF RFCs at <http://www.ietf.org/rfc.html>. Relevant standards include HTTP, MIME, etc.
ISO	International Organisation For Standardization (ISO). See <http://www.iso.org/iso/en/stdsdevelopment/whowhenhow/how.html>. Relevant standards areas include character sets, networking, etc.
NISO	National Information Standards Organization (NISO). See <http://www.niso.org/>. Relevant standards include Z39.50.
IEEE	Institute of Electrical and Electronics Engineers (IEEE). See <http://www.ieee.org/>.
ECMA	ECMA International. Association responsible for standardisation of Information and Communication Technology Systems (such as JavaScript). See <http://www.ecma-international.org/>.

Other Types Of Standards

The term proprietary refers to formats which are owned by an organisation, group, etc. The term industry standard is often used to refer to a widely used proprietary standard. For example, the proprietary Microsoft Excel format is sometimes referred to as an industry standard for spreadsheets. To make matters even more confusing, the prefix is sometime omitted and MS Excel can be referred to as a standard.

To further confuse matters, companies which own proprietary formats may choose to make the specification freely available. Alternatively third parties may reverse engineer the specification and publish the specification. In addition tools which can view or create proprietary formats may be available on multiple platforms or as open source.

In all these cases, although there may appear to be no obvious barriers to use of the proprietary format, such formats should not be classed as open standards as they have not been approved by a neutral standards body. The organisation owning the format may chose to change the format or the usage conditions at any time. File formats in this category include Microsoft Office formats, Macromedia Flash and Java.

References

Open Standard, Wikipedia, <http://en.wikipedia.org/wiki/Open_standard>
Open Standard: European Union definition, Wikipedia, <http://en.wikipedia.org/wiki/Open_standard#European_Union_definition>

Briefing 31

Matrix for Selection of Standards

Background

JISC and the JISC advisory services provide advice on a wide range of standards and best practices which seek to ensure that project deliverables are platform and application-independent, accessibility, interoperable and are suitable for re-purposing.

The standards and best practices which JISC advisory service recommend have been developed with these aims in mind.

Challenges

Although use of recommended standards and best practices is encouraged, there may be occasions when this is not possible:

Building on existing systems: Projects may be based on development of existing systems, which do not use appropriate standards.

Standards immature: Some standards may be new, and there is a lack of experience in their use. Although some organisations may relish the opportunity to be early adopters of new standards, others may prefer to wait until the benefits of the new standards have been established and many teething problems resolved.

Functionality of the standard: Does the new standard provide functionality which is required for the service to be provided?

Limited support for standards: There may be limited support for the new standards. For example, there may be a limited range of tools for creating resources based on the new standards or for viewing the resources.

Limited expertise: There may be limited expertise for developing services based on new standards or there may be limited assistance to call on in case of problems.

Limited timescales: There may be insufficient time to gain an understanding of new standards and gain experience in use of tools.

In many cases standards will be mature and expertise readily available. The selection of the standards to be deployed can be easily made. What should be done when this isn't the case?

A Matrix Approach

In light of the challenges which may be faced when wishing to make use of recommended standards and best practices it is suggested that projects use a matrix approach to resolving these issues.

Area	Your Comments
Standard
How mature is the standard?
Does the standard provide required functionality?
Implementation
Are authoring tools which support the standard readily available?
Are viewing tools which support the standard readily available?
Organisation
Is the organisation culture suitable for deployment of new standards?
Are there strategies in place to continue development in case of staffing changes?

Individual projects will need to formulate their own matrix which covers issues relevant to their particular project, funding, organisation, etc.

Implementation

This matrix approach is not intended to provide a definitive solution to the selection of standards. Rather it is intended as a tool which can assist projects when they go through the process of choosing the standards they intend to use. It is envisaged that projects will document their comments on issues such as those listed above. These comments should inform a discussion within the project team, and possibly with the project's advisory or steering group. Once a decision has been made the rationale for the decision should be documented. This will help to ensure that the reasonings are still available if project teams members leave.

For examples of how projects have addressed the selection of standards can see: