UKOLN Briefing Paper

Selection and Use of Open Standards
Open standards can provide many benefits including platform independence and interoperability. But although many successful services have used open standards there are also times when open standards fail to to live up to their expectations. This briefing document summarises the potential benefits of open standards but provides examples of possible limitations. A contextual approach to assist the selection of open standards is described which aims to minimise the risks that open standards which subsequently fail to provide the expected benefits are used. WHY USE OPEN STANDARDS?
The use of open standards aims to maximise the benefits of the investment in development activities. Open standards can help to achieve this by providing: Application-independence: So that resource can be processed by a wide range of applications and aren‟t locked in to a particular vendor. Device-independence: So that services can be accessed on a variety of devices, including various desktop computer environments, mobile devices, etc. Architectural integrity: The development processes for production of open standards aims to ensure that systems can be integrated with other new areas of development. Long-tem access: Application and device-independence can help ensure that services can be accessed in the future, when existing applications may no longer be available. Wide accessibility: Application and device-independence can help ensure that services can be accessed by people with disabilities using a variety of assistive technologies. In brief open standards can provide a level playing field in which multiple providers can develop a diversity of services which can stimulate competition and drive down prices, provide richer functionality and enhanced usability. Note that CETIS have published a briefing paper on “Assessing the Business Case for Standards, an introduction for strategy and resourcing committees” [1] which provides further examples of the benefits of open standards. If an open standard is defined as its ownership and governance then there will be a need to be able to identify key standards-making organisations. Examples of recognised open standards bodies include W3C (responsible for the development of Web standards); IETF (responsible for the development of Internet standards); ISO (an internationalstandard-setting body composed of representatives from various national standards bodies) and ECMA (responsible for standardisation of Information and Communication Technology Systems such as JavaScript).

OTHER TYPES OF STANDARDS
The term proprietary refers to formats which are owned by an organisation, group, etc. Since this term has negative connotations, 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 have traditionally included Microsoft Office formats, Adobe's PDF, Macromedia Flash and Java.

WHAT ARE OPEN STANDARDS?
The benefits which open standards aim to provide can be summarised by the statement “Open standards provide interoperability”. But what, exactly, is an open standard? Perhaps surprisingly it seems that the term "open standards" is somewhat ambiguous and open to different interpretations. Open standards can mean: A standards-making process open for anyone to participate in. Documentation on the standards is available for free or at a reasonable cost. Use of the standards is unencumbered by licensing or patenting issues. The standards are ratified by recognised standards body. .

COMPLEXITIES OF OPEN STANDARDS
Despite the widespread acceptance of the importance of open standards and the feeling among some that use of open standards should be mandatory in the development of networked services in practice organisations may not implement open standards due to several factors:

Failure in the Market Place: Open standards may not succeed in gaining acceptance in the market place if they do not align with major vendors' business models or interests. In such cases, real or perceived flaws such as over complexity and the need to change user habits override the advantages of open standards and existing closed solutions are used instead. Conversely, if there is strong alignment of an open standard to vendors' interests, problems in the standard itself tend to be overcome with rapid development of new versions and strong products. Failure to Satisfy User Needs and Expectations: An over-emphasis on immature open standards may be detrimental to the end user even if beneficial to developers or service providers. Difficulties in Mandating and Enforcing Compliance: There can be difficulties when mandating open standards. For example: What exactly does „must‟ mean? When told you must comply with HTML standards, developer s working on a project might ask, „What if I don‟t?‟ and „What if I use PDF instead of HTML?‟ There is a need to clarify the meaning of must and for an understandable, realistic and reasonable compliance regime. Such complexities are also acknowledged in the EU‟s Interoperability Framework [2]. Despite such reservations, in reality many IT development programmes are successful. The success may be based on the deployment of agreed-upon and well-defined open standards. However in other cases, development work may adopt a more pragmatic approach, making use of mature open standards but having a more flexible approach to newer standards when there has been no time to reflect on the strengths and weaknesses and the experiences gained in their use

These examples illustrate the dangers, which may include cost implications in addition to user dissatisfaction, which an uncritical adoption of open standards may lead to.

A SPECTRUM OF OPENNESS
In addition to the experiences of when the success of acknowledged open standards is questionable there is also a need to consider the relevance of standards which may not necessarily be regarded as an open standard. Consider, for example, RSS and PDF and MS Office file formats. Which, if any, of these can be regarded as an open standard? RSS: RSS is widely used for content syndication and is provided as standard on many blog platforms. RSS actually nowadays refers to two different formats: RSS 1.0 stands for RDF Site Summary whilst the apparently newer version RSS 2.0 is a different standard which standards for Really Simple Syndication. Although the standards provide similar functionality they have different governance regimes. In addition neither format seems to have a stable governance responsible for the continued development of the formats. Despite such concerns (and the development of the IETF Atom standard which sought to provide more stable governance for a related standard) in practice the development community has been willing to make use of both versions of RSS, with libraries available for processing data provided in either of the formats. PDF: The PDF format was developed by Adobe. Although the format was widely regarded as an open standard it was only in 2005 that the PDF/A archival format was standardized by ISO and 2008 when PDF 1.7 itself became an ISO standard. MS Office formats: Microsoft are renowned for their proprietary formats so it might appear self-evident that their Office formats will be proprietary. However in 2008 ISO standardize the latest version of the Office file format as the OOXML format. This format is acknowledged to be complex and seems to compete with a simple open standard for office documents, ODF. In addition documents created by MS Office applications will not necessarily conform with the standard. But despite such criticisms the OOXML is an open standard. From these examples we can see that: There is a spectrum of openness: Formats may not be governed by a stable trusted and neutral governance body. However such formats are also not owned by a single organisation which can benefit financially by making changes to the format or terms and conditions for its use. Proprietary formats may evolve to being open: Such evolution may be driven by pressure from the user community (especially large-scale global organisations) or by government pressure (e.g. pressure from the US Government bodies such as the Department of Defense on Microsoft for their Office formats to be standardised). It should be therefore noted that there may be circumstances in which the use of open standards may not be the most appropriate decision to make for a development project. The challenge, therefore, is to ensure that informed decisions are made and that risks are identified and minimised.

EXAMPLES OF THE LIMITATIONS OF OPEN STANDARDS
In order to illustrate the difficulties in mandating use of open standards a number of case studies are provided: Coloured Book software: In the 1980s the Computer Board, which funded IT developments in the UK Higher Education sector, mandated use of Coloured Book networking software to as a transition to ISO OSI network standards, with central IT services in universities being barred from adopted emerging TCP/IP protocols. It was only in the light on increasing pressures from the research community who found lack of Internet access a significant barrier to engagement with the international community that the ban was relaxed and, at a later date, scrapped as the UK HE community adopted Internet protocols. SMIL and SVG: The W3C‟s SMIL (Synchronized Multimedia Integration Language) and SVG (Scalable Vector Graphics) standards were developed to provide rich and interoperable access to multimedia and graphical formats on the Web. Since these standards had been developed by the W3C after the success and widespread take-up of HTML and, at a later date, CSS, it was felt that these formats would be quickly adopted and replace proprietary alternatives such as Flash. In reality these formats failed to gain acceptance in the market place and Flash continued to dominant role in the provision of highly interactive Web-based services.

A CHECKLIST FOR STANDARDS
In light of the concerns described above a simple checklist to assist technical managers and policy makers on decisions regarding the selection and use of open standards has been developed by UKOLN. The checklist is described in the paper “Interoperability Across Digital Library Programmes? We Must Have QA!” [3] and is summarized in Table 1.

Area
Ownership Development processes Availability Software for use by readers, creators and developers. Fitness for purpose Resource issues Complexity Interoperability

Issues
Is standard owned by a recognised open standards body? Is there a community process for developing the standard? Has the standard has been openly published? Are software tools (a) available for free, (b) available as open source and (c) available on multiple platforms? Is the standard appropriate for the purpose envisaged? What are the resource implications in using the standard? How complex is the standard? What is the degree of interoperability between applications that claim to implement the standard? How easy will it be to deploy the deliverable into service? Is the standard suitable for long term preservation? What approaches can be taken to migrating to more appropriate standards in the future?

Figure 1: Contextual Approach to Selection of Standards This approach aims to provide the flexibility needed in light of the various complexities described above. In addition there is a need to ensure that the experiences gained in use of open standards, whether such experiences are positive or negative. In order to ensure that such experiences can be shared across the development community, and, ideally, more widely, a support infrastructure has been developed which is illustrated in Figure 2.

Service deployment Preservation Approaches to migration

Table 1: Checklist to Assist Selection of Standards

A CONTEXTUAL MODEL FOR THE SELECTION AND USE OF OPEN STANDARDS
The checklist given above is intended for use in the context of a specific development project. In order to provide a framework for programme managers and funders with a broader approach for advising or mandating projects in their use of standards a contextual model has been developed, which was initially described in a paper on “Openness in Higher Education: Open Source, Open Standards, Open Access” [4]. As illustrated in Figure 1 the model makes use of a contexual approach in which decisions on the section of standards is determined by various contextual aspects, such as levels of funding; available expertise; etc. This context will determine the flexibility which funded projects may have in the selection of appropriate standards. The funding body will also determine policies on ensuring conformance with such policies, which could range from formal external validation through to peer assessment and self-assessment or even getting things wrong and learning from such mistakes. Figure 2: Illustration of Support Infrastructure The support infrastructure ensures that experiences gained in the application of the contextual approach can be shared across the community. This can help ensure that policies for future development work are based on evidence of previous successes and failures. The experiences can be provided in distributed knowledge base which may include case studies and other centrally managed resources through to resources such as Wikipedia (although, of course, information gathered from such sources will need to be evaluated carefully). In addition to the knowledge based a communications infrastructure, which may include project email lists, Twitter, etc. enables discussions which inform policies and implementations to take place.

OPPORTUNITIES AND RISKS APPROACH TO USE OF OPEN STANDARDS
An opportunities and risks has been developed by UKOLN which was presented as a position paper [5] at a CETIS meeting on the Future of Interoperability Standards. This framework aims to support decision-making processes regarding the selection of emergent new standards which may be mandated in development programmes or the use of such standards by projects. Those wishing to make use of emergent standards should document: Intended purpose: Specific details of the intended uses of a standard should be provided. Perceived benefits: Let‟s not use open standards simply because they are open; rather there‟s a need to provide details of the expected benefits. Perceived risks: A summary of the perceived risks which use of the standards may entail should be documented. Missed opportunities: Details of the missed opportunities and benefits which a failure to use open standards should be documented. Costs: The resource implications of use of the standards should be documented. Risk minimisation: Once the risks have been identified approaches to risk minimisation should be documented. Evidence base: Evidence which back up the assertions made in use of the framework.

REFERENCES
1. Assessing the Business Case for Standards, CETIS <http://www.jisc.ac.uk/publications/briefingpapers/2009/b pbusinesscaseforstandards.aspx> 2. Towards Interoperability For European Public Services, Annex II (European Interoperability Framework), EC, <http://ec.europa.eu/isa/strategy/doc/annex_ii_eif_en.pdf> 3. Interoperability Across Digital Library Programmes? We Must Have QA!, Kelly, B. Proceedings of the Research and Advanced Technology for Digital Libraries, ECDL 2004 Conference, <http://www.ukoln.ac.uk/qafocus/documents/papers/ecdl-2004/> 4. Openness in Higher Education: Open Source, Open Standards, Open Access, Kelly, B., Wilson, S. and Metcalfe, R. ELPUB2007, <http://www.ukoln.ac.uk/webfocus/papers/elpub-2007/> 5. An Opportunities and Risks Framework For Standards, Kelly, B, UK Web Focus blog, 6 January 2010, <http://ukwebfocus.wordpress.com/2010/01/06/anopportunities-and-risks-framework/>

ABOUT THIS BRIEFING PAPER
This briefing paper summarises several years of UKOLN work in developing approaches to exploit the benefits of open standards. The approaches described have been previously published in several papers which are available from <http://www.ukoln.ac.uk/web-focus/papers/#standards>. Our initial work in this area was developed as part of the JISC-funded QA Focus project which developed a quality assurance framework for JISC programmes. A paper on “Developing a Quality Assurance Culture For Digital Library Programmes” published in 2003 proposed a self-assessment approach for checking conformance with standards and other best practices. The adoption of such approaches was subsequently described in “Deployment of Quality Assurance Procedures for Digital Library Programmes”. A paper on “A Standards Framework For Digital Library Programmes” published in 2005 by staff from UKOLN, CETIS, AHDS and TechDis showed a shared understanding of the complexities of use of open standards and introduced the layered approach to use of open standards. The importance of context in use of open standards was highlighted in a paper on “A Contextual Approach to Standards” which was written by staff from UKOLN, CETIS, AHDS, OSS Watch and TechDis in 2006. The contextual approach was further developed in a paper on “Addressing The Limitations of Open Standards” in 2007. In a paper on “Openness in Higher Education: Open Source, Open Standards, Open Access” staff from UKOLN, CETIS and OSS Watch outlined the similarities in approaches for the selection of use of open standards, open source software and open content. A position paper on “An Opportunities and Risks Framework For Standards” was presented at CETIS‟s Future of Interoperability Standards event which introduced the opportunities and risks framework.

CONCLUSIONS
This briefing paper has described approaches for the selection and use of open standards which have been developed at UKOLN in conjunction with other JISC-funded organisations. The paper has described the following approaches: Use of a simple checklist approach which can be used by those involved in the section of appropriate open standards in a specific project or development activity. A layered model to assist programme managers or those involved in developing policies across a set of development activities. A support infrastructure to ensure that the experiences gained are shared with others. An opportunities and risks model which ensures that possible risks in the selection of new or immature standards are identified and documents and risk minimisation plans developed.

This document is available under a Creative Commons BY-NC-SA 2.0 licence Version 0.3 published on 4 February 2011

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times