QA Toolkit: Open Standards

Status

This self assessment toolkit was developed as a prototype for the JISC-funded QA Focus project. Please note that the prototype was not formally deployed as a service. The toolkit is no longer being maintained.

About

This toolkit forms part of the QA Focus Toolkit and is based on the What Are Open Standards? briefing paper.

The QA Focus Toolkit works as part of the QA Focus methodology which is based on documented policies on standards and best practices, systematic checking and audit trails.

A full explanation of the QA Focus methodology is available in the Methodology Briefing paper.

Go straight to the Open Standards toolkit.

Why Use Standards?

Use of well recognised standards on your project is advocated by JISC and advised by many public sector bodies. Standards are an important part of project work because they:

• Facilitate interoperability between systems through application and platform independence
• Ensure that your resources can be accessed by people regardless of disabilities
• Facilitate long-term access to your resources
• Enforce rigour in internal practices
• Allow us to benefit from the expertise of others

Further information on the standards that are of relevance to projects funded by JISC is available in the Standards and Guidelines to Build a National Resource document .

What are Open Standards?

The term "open standards" is ambiguous and means different things to different people. definitions include:

• An open standards-making process
• Documentation freely available on the Web
• Use of the standard is uninhibited by licencing or patenting issues
• Standard ratified by recognised standards body

Although an open standards approach may seem appealing, in practice there will be occasions when use of proprietary solutions may be needed (for example, there may be areas in which open standards are not available or are not sufficiently mature for deployment in a service environment). To clarify the term proprietary refers to formats which are owned by an organisation, group, etc.

An awareness that developers may be faced with a choice leads to the need for that choice to be an informed one. This module of the QA Focus Self Assessment Toolkit aims to advise Web developers on several factors to consider when choosing formats for use when developing resources.

The following factors need to be considered when deciding upon a new format, standard or piece of software for use by your project. Tick the boxes that apply to the format being considered.

Open Standards Toolkit

This toolkit is designed to stimulate open discussion between project staff. It is not an auditing tool in itself.

To use the toolkit you need to answer the questions in the online form below and submit the page. A page will then appear with a list of comments on your answers. QA Focus does not keep a record of the answers submitted.

Note that when filling in the form:

• Radio buttons () limit you to one of the options given (i.e. only one button can be selected).
• Check boxes () let you select as many of the options as you would like (i.e. many buttons can be selected).

1. Ownership of Standard
The standard is owned by an acknowledged open standards body?
The standard is owned by a neutral body, but not (yet) formally adopted as an open standard (e.g. Dublin Core)?
The standard is owned by a company (i.e. a proprietary standard)
2. Openness of Proprietary Format
If the standard is proprietary:
There is an open development process (e.g. Sun's Java Community Programme)?
The specification is published openly (e.g. Microsoft's RTF)?
The specification has been published by third parties reverse-engineering the specification (e.g. Microsoft's Word)?
The specification has not been published?
3. Availability of Viewers
Are viewers for the format:
Available free of charge?
Available on multiple platforms?
Available as open source?
4. Availability of Authoring Tools
Are authoring tools for the format:
Available free of charge?
Available on multiple platforms?
Available as open source?
5. Functionality of the Standard
Does the standard provide:
Rich functionality?
Basic functionality?
6. User Requirements
Does the standard:
Largely provide the functionality required by end users of the service?
Adequately provide the functionality required by end users of the service?
Insufficiently provide the functionality required by end users of the service?
Largely fail to provide the functionality required by end users of the service?
7. Fitness for Purpose
Is the standard:
Ideal for the purpose envisaged?
Appropriate for the purpose envisaged?
Not particularly appropriate for the purpose envisaged?
8. Resource Implications
Will use of the standard:
Have significant staffing implications for development and maintenance?
Have relatively few staffing implications for development and maintenance?
Have significant financial implications for development and maintenance?
Have relatively few financial implications for development and maintenance?
9. Preservation
Is the format:
Easy to preservation?
Difficult to preserve?
You are unsure of the ease of preservation?
10. Migration
If it becomes necessary to migrate to an alternative format will it be:
Easy to migrate to alternative formats?
Difficult to migrate to alternative formats?
11. Stability of Standard
Does the standard change:
Often?
Occasionally?
Rarely?
12. Cultural Factors
As well as the various technical issues addressed above, there is also a need to consider the organisational culture of the developers. For example is your organisation:
Keen to make use of innovative developments?
Keen to make use of mature solutions?

Note that QA Focus does not keep a record of the answers submitted.