DigRepStandards-FullDocument

From DigiRepWiki

Contents

[edit]

Full Document

[edit]

Introduction

[edit]

About This Document

Welcome to the Standards For The JISC Digital Repositories Programme document. This document provides details of the standards which will be of relevance to projects funded by JISC's Digital Repositories Programme.

[edit]

Scope Of This Document

This document addresses the technical standards for use by projects to support interoperability. It should be noted that the document does not address:

  • Accessibility and usability issues
  • Specific applications or technical architectures
[edit]

Approach Taken On The Selection And Use Of Standards

[edit]

Background

UKOLN, a national centre of expertise based at the University of Bath, has been asked by the JISC to take responsibility for the development and maintenance of advice on the technical standards to be used by projects funded by JISC's development programme.

The approach which has been taken is based on the recommendations of the JISC-funded QA Focus project which was provided by UKOLN and the AHDS. Following discussions with several projects and JISC staff it was acknowledged that the use of open standards can help to support the interoperability of project deliverables which is of particular importance to the JISC environment and the higher and further education communities, in light of the diversity which is encountered within this sector. However, despite the acknowledged importance of open standards, it was also recognised that the selection and use of open standards is not always easy. There is an awareness that not all open standards gain widespread acceptance and that adoption of open standards before they have proven their reliability and gained widespread acceptance can be costly (as has been seen with the experiences of the planned transition to OSI networking protocols through use of Coloured Book software in the 1980s). In addition to such issues, there is also a recognition that use of open standards may not be applicable in all contexts. For example use of open formats in areas such as word processing, spreadsheets and databases may cause problems in interoperability; in such circumstances in may be sensible to continue to make use of proprietary solutions.

[edit]

A Layered Approach To Use Of Open Standards

In light of this, a layered approach to use of standards has been developed. This approach, whilst encouraging use of open standards to enhance interoperability, will permit alternative approaches if use of open standards can be shown to be too costly or difficult to implement. In such cases there will be a need to demonstrate the case for deviance from best practices.

The layered approach makes use of three layers (which is described more fully in "A Standards Framework For Digital Library Programmes" <http://www.ukoln.ac.uk/web-focus/papers/ichim05/>- a paper presented at the ichim05 conference.

This approach is illustrated below. <img src="kellyS02-figure-2.gif" />

The layers are summarised below:

  • Contextual layer: This reflects the context in which the standards are being used. Large, well-funded organisations may choose to mandate strict use of open standards in order to build large, well-integrated systems which are intended for long term use. For a smaller organisation, perhaps reliant on volunteer effort with uncertain long-term viability, a simpler approach may be more appropriate, perhaps making use of proprietary solutions.
  • Policy layer: This provides a description (or catalogue) of relevant policies in a range of areas. The areas will include descriptions of standards, the topic of this paper.
  • Compliance layer: This describes the mechanisms which will be used in order to ensure that development work complies with the requirements defined within the particular context. For large, public funded programmes there could be a formal monitoring process carried out by external auditors. In other contexts, projects may be expected to carry out their own self-assessment. In such cases, the findings could be simply used internally within the project, or, alternatively, significant deviations from best practices could be required to be reported to the funding body.
[edit]

Application Of This Approach To The Digital Repositories Programme

The layered approach described above is a generic approach which can be applied across JISC's development programmes (and indeed more widely). The application to the Digital Repositories Programme is described below

  • Contextual layer: The JISC programme manager (and associated bodies and individuals) are responsible for defining the application of the standards for projects funded by the programme and for defining reporting procedures and quality assurance processes.
  • Policy layer: This document describes the technical standards which may be of relevance to the projects.
  • Selection layer (note not included in above diagram): The projects themselves will be responsible for developing and documenting the technical architecture to be used. This will include the selection of relevant standards. The JISC programme manager will advise on areas in which projects can make such decisions for themselves and areas in which decisions need to be ratified (by the programme manager or by other bodies, such as a project advisory group)
  • Compliance layer: The projects themselves should develop quality assurance procedures which will ensure that their technical (and other) policies are being implemented appropriately. Self assessment may be needed for internal management purposes. In addition the JISC programme manager may require notification of significant deviations from best practices. In addition to such self assessment, the JISC programme manager may chose to require additional reporting or assessment processes.
[edit]

Example

An example of an implementation of this approach is given below.

This example covers use of standards for a project Web site.

  • Contextual layer: The JISC programme manager may require that project Web sites should seek to implement appropriate open standards, including HTML and CSS, and require projects to document its decisions and its QA processes and to report on any significant deviations from this policy.
  • Selection layer: A project may choose HTML 4 (or XHTML 1) and CSS 2.0 and to implement this using a CMS. This decision should be documented - possibly on its Web site so that not only is JISC aware of the decisions, but also the wider community, including potential other stakeholders (e.g. a service which may wish to archive the Web site).
  • Compliance layer: The project's compliance regime could include systematic validation processes and audit trails to record trends. There may be legitimate deviations from best practices e.g. !PowerPoint files converted to HTML may not comply with HTML standards.
[edit]

Key Standards For The Digital Repositories Programme

This section provides access to the standards which are of direct relevance to the Digital Repositories Programme.

[edit]

Key Standards

[edit]

Other Relevant Standards For The Digital Repositories Programme

This section provides access to the standards which are likely to be of relevance to the Digital Repositories Programme. These are:

[edit]

Web Standards

The section covers standards for Web sites including HTML, CSS (Cascading Style Sheets), and DOM (Document Object Model).

[edit]

HTML / XHTML

Standard: HTML

About the Standards: HTML is the native Web format for the Web. HTML describes the structure of native Web documents.

Version: At the time of writing (27 July 2005) the recommended versions of HTML are HTML 4 and XHTML 1.

Maturity: HTML is a mature format, with many authoring tools available and a wide understanding of the technologies. (XHTML 1.1 is the latest version and is widely supported.)

Risk Assessment: Historically HTML provided both structural and formatting elements and many tools still support this approach. Use of CSS has, in the past, been hindered by poor support in browsers, although simple techniques are now available for overcoming such barriers. However inertia, investment in legacy authoring tools or a lack of awareness of current best practices may hinder deployment of HTML and CSS with corresponding difficulties in maximising accessibility and interoperability.

In addition there is a need to ensure documents using HTML comply with appropriate standards. There will be a need to deploy appropriate QA techniques to ensure that this is the case.

Also note that there are some minor issues concerning the MIME type to be used with XHTML 1 resources. In practice, however, there is a widespread, but not universal, view that the same MIME type can be used for both HTML and XHTML 1 resources.

SOA Role:

Further Information:

Author: Brian Kelly, UKOLN

Contributor:

Date Created: 1 June 2005

Update History:

[edit]

CSS

Standard: CSS (Cascading Stylesheets).

About the Standard: CSS Cascading Stylesheets) is the recommended technology for describing the appearance of HTML documents.

Version: At the time of writing (1 June 2005) the recommended version of CSS is CSS 2.

Maturity: CSS is a mature format, with many authoring tools available and a wide understanding of the technology.

Risk Assessment: Historically use of CSS has, in the past, been hindered by poor support in browsers, although simple techniques are now available for overcoming such barriers. However inertia, investment in legacy authoring tools or a lack of awareness of current best practices may hinder deployment of HTML and CSS with corresponding difficulties in maximising accessibility and interoperability. In addition there is a need to ensure documents using CSS comply with appropriate standards. There will be a need to deploy appropriate QA techniques to ensure that this is the case.

SOA Role:

Further Information:

Author: Brian Kelly, UKOLN

Contributors:

Date Created: 27 July 2005

Update History:

[edit]

DOM

Standard: DOM (Document Object Model)

About the Standard: The DOM (Document Object Model) is a platform- and language-neutral interface for Web resources (such as HTML and XML) that allows programs and scripts to dynamically access and update the content, structure and style of documents.

Version: Level 3 of various components of the DOM is the latest version.

Maturity: The DOM is widely used to provide interaction in Web pages.

Risk Assessment: There may be inconsistent support for DOM across various Web browsers and JavaScript implementations. There will be a need for testing across browser environments. Also note that support for the DOM may be disabled if users (or institutions) disable JavaScript support).

SOA Role:

Further Information:

Author: Brian Kelly, UKOLN

Contributors:

Date Created: 22 July 2005

Update History:

[edit]

Alerting Standards

The section covers alerting standards including RSS, Atom and OPML.

[edit]

RSS

Standard: RSS is a widely used standard for news feeds and content syndication.

About the Standard: RSS provides a simple mechanism by which news can be described and made available. RSS alerts can be easily embedded in Web pages, aggregated by RSS aggregation tools, viewed in dedicated RSS readers, etc.

Version: Confusingly the term 'RSS' covers two separate formats. In RSS 1.0 the term standards for RDF Site Summary whereas in 'RSS 2.0' (which is a different, and not later, version to RSS 1.0) RSS standards for Really Simple Syndication.

Maturity: RSS is widely used, is simple to create and is a very powerful technology.

Risk Assessment: The competing approaches and confusion in the terminology can result in an inappropriate version of RSS being used. At present RSS readers can normally process both versions, but this may not be the case in future.

SOA Role: Alerting.

Further Information:

Author: Brian Kelly, UKOLN

Contributor:

Date Created: 1 June 2005

Update History:

[edit]

Atom

Standard: Atom is an XML-based document format for the syndication of Web content such as Weblogs and news headlines.

About the Standard: Atom was developed as a replacement for the RSS famliy of standards for news syndication.

Version: version 1.0.

Maturity: Atom is widely used, is simple to create and is a very powerful technology.

Risk Assessment: Atom and the various versions of RSS provide related functionality.

SOA Role: Alerting.

Further Information:

Author: Brian Kelly, UKOLN

Contributor:

Date Created: 3 Feb 2006

Update History:

[edit]

OPML

Standard: OPML (Outline Processor Markup Language).

About the Standard: OPML (Outline Processor Markup Language) is a format which can be used for managing groups of RSS feeds.

Version: Not known

Maturity: RSS appears to be the main mechanism used for importing and exporting RSS feeds between RSS readers.

Risk Assessment: OPML was developed by Davey Winer. The format has not been adopted by a formal open standards body. However, in practice, developers of RSS tools appear to have accepted OPML as an industry standard.

SOA Role: Alerting.

Further Information:

Author: Brian Kelly, UKOLN

Contributor:

Date Created: 21 July 2005

[edit]

Other Standards WHich May Be Of Relevence To The Digital Repositories Programme

This section provides access to the standards which may be be of relevance to the Digital Repositories Programme.

[edit]

Other Standards

Retrieved from "/repositories/digirep/index/DigRepStandards-FullDocument"