This paper explores the issues and opportunities for specifications that develop outside of the traditional governance processes of industry consortia or formal standards organisations through a discussion and comparison of three specifications developed in the education sector: XCRI (eXchanging Course-Related Information), SWORD (Simple Web service Offering Repository Deposit), and LEAP2.0 (Learner Portfolios 2.0). In each case study, there are challenges, opportunities, and accomplishments, and the experiences of each project are compared to identify commonalities and differences. Based on these case studies, the paper applies the framework developed by Wilson and Velayutham (2009) to position the specifications against similar specifications from established consortia and formal standards. Finally, the topic of incubating specifications is discussed, with implications for funding agencies with an interest in supporting interoperability.
TopIntroduction
The term “informal specifications” or “informal standards” is often used when discussing initiatives that take place outside the framework of de jure standards. However, this term is also applied to mature specification consortia such as the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF); for example, Van Eecke and Truyens (2009) cite XML as an example of an informal specification.
Unlike specification consortia, the idea of “community specifications” or “community-driven specifications” is a fairly new characterization. While community-driven specifications are by definition also informal standards, they are also characterized separately from specification consortia.
For example, the Open Web Foundation describes its work as “an organization to facilitate community efforts to create technical specifications that conform to the ethos that anyone can use the specification and nobody “owns” the specification or its ideas” (Recordon, 2008).
While many of the characteristics set out by Recordon may be seen as aspirations rather than actual characteristics of such initiatives, there is a sense in which specifications such as OpenID, oAuth, OpenSocial and Microformats are developed differently from, for example, W3C or OASIS specifications.
It may be more accurate to describe the types of initiative the OWF supports as “single specification” communities; that is, communities formed to develop and promote a single specification to solve a single common problem, rather than an organisation that seeks to develop a range of specifications within some sort of agreed scope. However even this characterisation is not entirely satisfactory, as Microformats are commonly considered to be a community specification, and yet the Microformats community develops many different specifications in different areas.
Cooper (2010) characterises “Open Community Development” as: 1) very limited controls on participation by any interested party, either by minimal bureaucracy or peer pressure, 2) initiation by a group of people who have a common interest/need and form an ad-hoc group to meet the need, 3) development of prototypes/code interwoven with spec development, 3) an acceptance of rapid change, refactoring etc, 4) negligible formal process, 5) transparency/visibility of work in progress (on public web), 6) online and often async (sic) rather than f2f or sync (sic) participation.
It could be argued that the main difference between a community specification and specification consortia is principally one of maturity; IETF, for example, could be considered to be a specification community in the sense that it has no official membership and anyone can contribute to specifications.
The picture is further blurred by the fact that community specifications may also be submitted to established specification consortia or to formal standardisation processes, or communities may choose to become consortia with official membership and processes.
Another approach is to simply consider community specification development as one end of a spectrum of informal standardisation, with consortia such as W3C and OASIS at one end, close to formal standards in terms of process and organisational stability, and community specification development at the other, but with no single defining characteristic. Using this approach, the characteristics Cooper describes are useful heuristics for placing specification development initiatives along the spectrum; any individual initiative may have one or more such characteristics to be considered a “community specification”.
In the next section three initiatives are profiled that occupy the “community” end of the informal standards spectrum. The Joint Information Systems Committee of the UK Education Funding Councils1 (JISC) supported each of these initiatives; JISC is an agency that supports the ICT infrastructure for UK universities and colleges. In the cases presented in this paper, JISC provided support through a combination of funding implementations, and supporting communities through two of its Innovation Support Centres (ISCs), CETIS and UKOLN; these support centres provide expertise in technology and standards in the technology-enhanced learning (TEL) and repository domains respectively.