Matt Wilcox posted an interesting argument about the development of the CSS3 standard; I think the central points of the argument can be applied to SCORM and where we’re potentially headed with SCORM 2.0.
After explaining some of the shortcomings of the current approach taken by the CSS3 Working Group, Matt writes:
What does CSS need to overcome these problems? First let me say what I think it really does not need. It does not need more ill thought out modules that provide half-baked solutions to explicitly defined problems and take a full decade to mature. We do not need the Working Group to study individual problem cases and propose a pre-packaged “solution” that either misses the point, is fundamentally wrong, or is inflexible. […]
The crux of the issue is that W3C seem to try providing high-level “solutions” instead of low-level tools. It’s a limiting ideology. With the CSS3 WG strategy as it’s been over the last decade, they would have to look at all of the problem points I proposed above, and come up with a module to provide a solution to each. But by giving [designers low-level tool functionality], we designers can build our own solutions to all of them, and innumerable other issues we have right now, and in the future.
As with the discussion regarding ECMAScript “Harmony”, I think LETSI should take a look at the meat of this argument and apply it to SCORM 2.0. Test cases are important for SCORM moving forward, but we can’t try to predict every issue a course developer might encounter — the possibilities are too numerous, and as we learned with Web 2.0, we can’t predict what technology (esp. browser capabilities) will be dominant in 5 years. What we can do is provide a loose framework or toolset that gives developers the flexibility to build their courses the way they want. This system would ensure interoperability by standardizing the tools and data management across LMSs.