Tom King recently tweeted a great blog post on ZDNet by Jeremy Allison that teaches some great lessons about standards and the creation of true interoperability. The ZDNet post is a reaction to a post by Rob Weir that explains how Microsoft created an implementation of the ODF standard that, while strictly conformant, actually serves to reduce interoperability as a whole.
Achieving real interoperability requires that the implementer want to be interoperable. No matter how great a standard is, if an implementer doesn’t embrace it, interoperability for the industry as a whole suffers. Standards are merely tools which can be used or misused.
These discussions so closely parallel what happens in our industry that I had to repeat them here. These are some of my favorite quotes and they sum up the important points quite nicely (note the quotes are mixed from the two links above, and words in [square brackets] and emphasis are mine):
Surely if you implement a standard fully…, then you must have an interoperable product. So long as others also implement the standard as written, then everything should just work together. That’s the way things are supposed to work.
One of the reasons is that standards themselves are often not perfect…[people are] claiming the ODF standard itself is at fault.
Remember, it is not particularly difficult or clever to to take an adverse reading of a standard to make an incompatible, non-interoperable product. Take HTML…I could create a perfectly conformant browser implementation that makes all default text be 4-point Zapf Dingbats, white text on a white background. It would conform with the standard, but it would be perfectly unusable by anyone…you can create 100% conformant, but non-interoperable, implementations of most standards.
Standards are voluntary, written to help coordinate multiple parties in their desires for interoperability. Standards are not written to compel interoperability by parties who do not wish to be interoperable.
…if your sole goal is to claim conformance. If your business model requires only conformance and not actually achieving interoperability, then I wish you well. But remember that conformance and interoperability are not mutually exclusive options.
A complete cynic would say that was what was intended…causing confusion in the marketplace like this was designed to make customers scuttle back to the safety of only using Microsoft Office
Of course, I am not that cynical. I was taught to never assume malice where incompetence [lack of effort / taking the easy way out / having other priorities] would be the simpler explanation.
…the concept of “Working to Rule”. When a union is trying to negotiate with management, there are a broad range of options they can take before using the ultimate weapon of going on strike. One of these tactics is “Working to Rule”. Normally in a working day, there are hundreds of small rules that people ignore in order to get their jobs done. From refilling the coffee machine for themselves…to fixing small problems with the machines they use for the job. “Working to Rule” means deliberately obeying every single one of these rules…Punctilious observation of every possible rule in order to disrupt orderly working.
This is what Microsoft has done with ODF in SP2.
So how do you do real interoperability?
…we go out of our way to make sure we work with other vendors implementations. We attend interoperability testing conferences, where we work with the engineers of other vendors (including Microsoft engineers) to ensure that customers deploying any of our implementations don’t get any nasty surprises. We’ve changed our code to work with Windows 95 and 98, Windows mobile, Windows CE, Windows 7, Network Appliance, a host of un-named embedded versions of CIFS in different appliances, even old versions of OS/2. It’s not hard, it’s just careful, detailed work. The only rule is to follow the words of the Internet Engineering Task Force (IETF) for interoperability, “Be conservative in what you send, be liberal in what you will accept.”
Simply substitute “SCORM” for “ODF” above and you have a great explanation to questions we are often asked.
- “Why should I use the SCORM Engine instead of just using the ADL Sample Run-time Environment?”
- “I took a look at the specs, I think I can do this myself, it’s just code, why should I buy your products?”
- “What’s the big deal, it’s just XML and JavaScript?”
- “Why is your SCORM implementation so much better than X?”
- “Why does my content work in your product but not in X?”
True interoperability is the answer to all of these questions. Achieving true interoperability requires going beyond the standard. It requires implementing the intent of the standard. It requires understanding what the authors meant to say rather than just what made it into print. True interoperability means you need to be able to read the standard and interpret it as others might, be that interpretation right or wrong. Being truly interoperable requires testing, testing and more testing to ensure that your products work with everybody else’s. More importantly, true interoperability requires you to be ready and willing to make changes to accommodate other companies’ differences of opinions…and to be able to do so in a way that doesn’t conflict with other implementations. Like Jeremy Allison says, “It’s not hard, it’s just careful, detailed work.” At Rustici Software, achieving real SCORM interoperability is our mission. It isn’t something we do on the side, it’s not a back-burner task. SCORM isn’t something we do once and then move it, it is a constant process of evolution and innovation.
There are some that give SCORM a bad rap. I can understand where they are coming from. Unfortunately we have an industry where several of the largest vendors have “worked to rule”. Their implementations are technically conformant and they have a certification label from ADL, but they have stopped far short of achieving real interoperability. This can be incredibly frustrating to an end user and it’s easy to see how SCORM gets the blame. When you really get down into it though, SCORM is quite a good standard from a technical point of view.
I think the people often underestimate the difficulty of the problem that SCORM is trying to solve. It does look simple at first glance, but the devil is always in the details. The real complication comes from the “very many to very many” relationship between content producers and LMS’s. There are literally thousands of LMS’s out there (a fact that surprised me when we got into this business). Compare that to the number of consumers of HTML or ODF content. According to Wikipedia, just 5 web browsers make up 98.89% of the market usage. The LMS market is FAR more fragmented, yet the expectations for seamless interoperability are just as high.
Let’s just consider our expectations with HTML/CSS. Even after many generations of specifications, there are still slight variations in how web pages are rendered in different browsers. Just consider this blog home page as rendered in two of the top three browsers. Even when using the most common browsers, there are still slight differences. We know about these, they’re annoying, but it’s acceptable and those that seek to create interoperate by and large are able to.
(and as an interesting aside, compare the browser compatibility of this page, designed largely by me, vs our home page which was designed by professionals who know their way around browser quirks)
SCORM is no different, it certainly has its quirks, but by and large it enables interoperability for those who seek it. As Rob Weir says standards can’t “compel interoperability by parties who do not wish to be interoperable”. What standards cannot do however, customers and markets can. If your vendor is “working to rule” and hasn’t implemented SCORM in a truly interoperable way, it significantly decreases the value you can realize from their product and it brings down the industry as a whole. Let them know that it is not acceptable. As SCORM evolves, we will certainly do everything we can do close the loopholes, but SCORM will only be truly interoperable if the industry demands it.
