Fiercly complex ?
Posted on July 13 2003 by Pierre Gorissen
in reponse to The dynamic appearance model and implementing SCORM 1.3
I have to disagree on the "But it is also fiercely complex, which is why it was dropped when EML was morphed into IMS Learning Design." statement about Docbook. For one, because Docbook isn't complex, especially not if you compare it with some of the other specifications we have at the moment. It is a very straight forward, flat model which isn't that hard to understand. It of course is different if you try to understand the XSLT stylesheets that have been build for them, those really are fiercely complex, but that is the price you pay when you want to implement flexibility. A more compelling reason why is was good that Docbook was dropped during development IMS LD is, I think, that it is useless to duplicate functionality within a specification. The 'EML-docbook' wasn't really Docbook, since it was slightly modified, just like EML had something that could do almost the same as QTI can and LD left that out of the specification also. Which is good, because of the flexibility added in LD there is nothing at the moment that would prevent you from using IMS LD + IMS QTI + Docbook. You would first of course have to build a system that could interpret that combination, but the LD specification allows it and the Docbook part by far wouldn't be the most complex part to implement.
Though I think that Docbook is a great example of storing information in a neutral format with stylesheets for PDF, HTML, XHTML and support for SVG, MathML etc. (see also my discussion with David Carter-Tod about that last year here on the site: http://www.cetis.ac.uk/content/20020328101921) a big problem/question I think is: do we really want that ?
Because most SCORM packages I've seen so far are flashy, good looking, animated pieces of content. And *that* you can't create using Docbook. Sure, you could include a Flash animation in a Docbook file and include a image representation of it for the PDF conversion, but that would partially defeat the point of having Docbook in the first place.
Metadata support might also be a problem, of course you can link to a Docbook file from within a contentpackage and then add metadata for it in the contentpackage, but internally the DTD based Docbook information model has no room for extensions with for example LOM Metadata, so internally adding metadata to a section within a file isn't possible.
Develop a new EduDocbook then ? That might be the only option, but we'll need to remember that the existence of a good flexible set of XSLT stylesheets will determine the success (or failure). Without the means to convert the XML to the different needed formats and the means to customise that conversion process nobody will be willing to invest in the conversion of existing material to a EduDocbook format.
I'll be looking forward to the release of the document.
Fontys University of Professional Education
Educational Development Department
Replies to this post: