Blank (Media) Slate

This is just a quick, off the top of my head post about the similarities and differences I see between the terms “specifications” and “standards” and our approach to supporting them. It’s by no means an exhaustive treatise on the subject, but just common sense thoughts on a working framework about their usage.

When talking with people, it seems as if the two terms are often used interchangeably. In non-technical discussions this is probably a reasonable enough conflation. After all, most folks don’t need to make a distinction between the two. I believe, however, that it’s important to draw a line around each concept to illuminate some of the subtleties of meaning in some contexts.

So, in my style of rough-n-ready definitions to clarify discourse:

• Specification: A formalized definition for the way something should operate.
• Standard: A common way in which something operates.

You can look up more complete definitions in your favorite dictionary, but these seem to be reasonable enough to encapsulate the salient points. Barring any niggling nuances, you can see how the two have a significant overlap in utility. More interesting, and I think less understood, is how the two differ.

In a nutshell, there are a lot of specifications floating around that aren’t being used widely enough to be considered a standard (e.g. most APIs are well-specified, but not a standard beyond the walls of a single system). In general, any newly proposed specification toward common interoperability can’t really be termed a standard until it’s been widely adopted. On the flip-side, just because a technique for interoperability is pervasive enough to have become standardized doesn’t mean it’s backed by a specification (e.g. CSV is a common standard output format but there’s no agreed-upon specification governing its format).

Why does this matter? Well, for those of us working on issues surrounding interoperability between disparate systems need to make the distinction when evaluating various techniques. In some cases it’s likely we’ll opt to focus on an emerging standard, even if the specification hasn’t solidified, yet. In other cases, we’d have to sit on the sidelines before implementing a promising specification until it is widely adopted.

At the end of the day, the name of the game for us is connecting things together. A great specification without proven utility doesn’t really help reach that goal. An emerging standard method for connecting without an associated formalized definition can easily lead followers astray if the usage shifts. Assuming a higher degree of comfort with formalized approaches, there’s the question of how to encourage wider adoption of a new specification so that it has a chance of becoming a standard.

While I’d like to think we live in a logical world where solutions are selected purely on their merits, this isn’t generally the case. Instead, in this chicken/egg game, it’s a matter of being plugged into the discussions and betting on what can be seen within a reasonable adoption horizon.

For us, this means flexibility. Flexibility, in turn, means being resigned to a lack of assured clarity. We’re still in the early days of defining what it means to connect users with their data (in our case their interests and tastes in media). Fortunately, we’ve built a nifty set of tools that are flexible in supporting both nascent specifications as well as adopted standards without a lot of retooling.

These tools are rapidly coming online, and I look forward to seeing them put to the real world test supporting the user’s desire to remain in control over their interconnected data across various systems.