Scott's Workblog

This blog has moved! Go to my new blog!

June 30, 2006

More standards? Which? Why?

Michael Feldstein picks up the thread on reactions to Alt-i-Lab, IMS's annual smile-for-the-public show.

I work in standards. I've worked on educational technology standards. I've even worked on IMS educational technology standards. However, 'more' standards is not necessarily more connections, more integration, more possiblities. Its a more complicated situation.

(For the pedantic: replace 'standard' with 'standards and/or specifications' as appropriate)

IMS has a huge back catalogue of released specifications. Some were developed far too early for their target problem space (LIP, ePortfolio) and have encoded obsolete thinking. Some developed too slowly to keep pace with general technology (e.g. Enterprise has slipped against general provisioning via SPML, DSML and directory services technology). Some doesn't seem to solve a real problem at all (SSP, VDEX). Some are now in direct competition with lightweight web specifications (Content Packaging vs. Atom/RSS, LOM vs. Dublin Core and tagging) and looking clumsy and irrelevant (well, IMHO anyway). At least one seems primarily to exist to support the business models of large publishers (Common Cartridge).

I've been struggling through the PLE work here recently to identify actual cases where new specifications are genuinely needed, and so far we've just identified a couple of areas for initial experimentation. Certainly nothing is saying to me right now that there is a massive standards gap somewhere (if you think there is, please let me know). And as the IMS experience has shown very clearly, once you've started its very hard to walk away from a spec - the only way to "deprecate" a specification is to ignore it. They are also, in formal consortia, very, very expensive to develop (also, as Tim Bray puts it, "its neither easy nor fun".

So we've not just got to pick the problem space, we also have to get the timing right. Too early, and you start to set in stone assumptions that may prove with experience to be incorrect. Too late, and proprietary solutions dominate the space.

We need to be very careful in our judgement - educational technology is now awash with competing standards, many of which are large, complex, and expensive to implement. While one can applaud IMS's enthusiasm, I think a little reflection on why we make standards in the first place could go a long way towards avoiding repeating past mistakes.

In our corner of the space, one of the few specification activities I've put effort into recently has been XCRI, a fairly simple specification for expressing course descriptions for administrative and marketing purposes - typically prospectus information, and admissions services. It serves a real need, there wasn't anything there before, and we have some genuine adoption at the grassroots. Better still, I didn't develop it, the people who needed it did.

Maybe in a year if there is enough evidence the approach is scalable, well-adopted, and fit for purpose then we might take it to IMS or someone else for standardization. But I think we have to stop pretending we're inventing the web like Tim Berner's Lee, and experiment at small scale first, and better still in public, to see if the concept is useful before attempting to develop standards.

For me this is also where the e-Framework should be helpful - it should let us identify where we've already been, what exists in the wider world (either as specifications, or de-facto services), and stop us writing unecessary XML schemas.

main archive