Working in the realm of standards (on the web or elsewhere) you eventually realise that there are a lot of terms, not all of which mean what they may initially seem to, or what they are always used for. This post is an attempt to simply explain some of these common concepts.
Specifications
Or ‘specs’. These are formal documents describing a technology, protocol, or other pattern that may be standardised. A standard cannot exist without a specification, but a specification is not automatically a standard of any kind. Specifications are key in allowing interoperability.
Examples: OAuth, OpenID, EAUT, PortableContacts, HTML4.01, XMPP
Interoperability
Is when two or more implementations of a specification can “talk to” each other, without prior knowledge of the other implementation.
Examples: Psi and Google Talk, Firefox and Opera, USB keys
Implementation
A product, service, or similar that conforms (or claims to conform) to a particular specification.
Standards Body
Or standards organisation. A self-proclaimed shepherd of standards. These bodies hold different amounts of influence with different implementors, based on their membership. Some of these bodies provide resources to those working on specifications they have claimed as “their standards”.
Standards bodies get all of their authority from their membership. These organisations may claim specifications are standards that no one outside them considers to be standards.
Examples: W3C, IETF, OASIS, ISO, ECMA
Open Specification
A specification that has been released to the public under a liberal license.
Standards Community / Open Community
A community that has rallied around a specification or set of specifications. The community seeks to promote and maintain the specifications, and often refers to them as “standards”.
Example: PortableContacts Initiative
An “open” community operates in the open, with transparency into all aspects and discussions. Usually operate on mailing lists and IRC channels.
Example: microformats community
Standard
Not everyone agrees what comprises a “standard”, but many people agree that the term is overused and abused. I will here state my own interpretation of “standard”:
- A standard has a specification
- The specification has multiple, independant implementations
- One or more of these implementations is interoperable
- One or more of these implementations is libre software
- One or more of these implementations is “popular”
- There is an implementation for each relevant platform (OSs, browsers, etc)
Notice that the blessing of a standards body or community is not necessary.
Examples: RTF, HTML4.01, XMPP, H.262
Open Standard
A standard whose specification is an open specification. In addition, the specification should be clear of all patent encumbrances (may be necessary to be considered an open specification).
Examples: OpenID, OAuth, XHTML1.1, microformats
3 Responses
Denver Gingerich •
In point 2 of the “Standard” section, I would suggest adding “independent” (ie. “The specification has multiple independent implementations”), which is based on section 4.1.2 of http://www.ietf.org/rfc/rfc2026.txt . This is an important distinction because implementations that are slightly different but share a codebase may have similar bugs that would otherwise have been exposed by testing with completely independent implementations.
As an example, Qt (the toolkit) would fit your unmodified definition of a standard. However, if “independent” were added as I suggested, Qt would not be a standard because the Qt implementations for various OSes share common code.
I suspect the omission of “independent” was an oversight; just wanted to make you aware of it.
The codec dilemma at A better world •
[…] of litigation. These are the reasons one should use any open standard (see Stephen Weber’s Beasts of the Standards World for a definition of “open standard”). By their nature, open standards foster […]
Implications of rtmpdump takedown at A better world •
[…] key to a free software project since they cannot hide the key. As a result, Flash cannot truly be a standard even if we ignore the codec patent problems. […]