Over the last few days a new notice has appeared on the IMS Question and Test Interoperability webpage in place of the QTI v2.1 draft specification:
The IMS QTIv2.1 draft specification has been removed from the IMS website. Adequate feedback on the specification has not been received, and therefore, the specification has been put back into the IMS project group process for further work.
QTI v2.1 was under public review for more than 2 years and did not achieve sufficient implementation and feedback to warrant being voted on as a final specification. Therefore it has been withdrawn for further work by the IMS membership. IMS cannot continue to publish specifications that have not met the rigors of the IMS process.”
IMS GLC has convened a set of leading organizations to take the lead on this new work – which will be considered to be in the CM/DN draft phase in the IMS process. Therefore, we are very encouraged and hopeful that a new version will be available in due time, possibly a QTI v2.2, along with the necessary conformance profiles. However, we cannot assume that it will be a linear evolution from QTI v2.1.
Until that time the only version of QTI that is fully endorsed by IMS GLC is v1.2.1, that is supported under the Common Cartridge Alliance: http://www.imsglobal.org/cc/alliance.html . While QTI version 2.0 has been voted on as a final specification by the IMS members, it’s deficiencies are well known and IMS does not recommend implementation of it.
This was clearly completely unexpected, not only for us at CETIS but also amongst a number of commercial and academic developers who have been working with the specification as can be seen by posts to the technical discussion list hosted by UCLES. In particular, I’d encourage you to read Wilbert’s response on behalf of CETIS.
Concerns from the developer community addressed a number of the issues raised in IMS’s statement. In response to the claim that ‘adequate feedback on the specification has not been received’, several commentators argued that this is because of the high standard of the specification; while the suggestion that ‘QTI v2.1 … did not achieve sufficient implementation … to warrant being voted on as a final specification’ sparked the addition of a number of implementations to Wikipedia’s QTI page.
There is agreement that work will progress on the basis of the public draft, so it is still perfectly possible that the outcome will be a mildly amended version of the public draft with some small profiles.
CETIS will be following this up, and will of course keep you all informed about progress. In the meantime, we’d be very keen to hear any thoughts or comments you have, although I would encourage you to sign up for both the UCLES list and the official IMS QTI list to ensure your voice is heard as widely as possible; it would be most beneficial for the wider QTI community I feel for discussion to be focused in one place, i.e. the UCLES list.
Hopefully, this will be worked out within IMS to the satisfaction of
all stakeholders. But what if it is not? If you were a
stakeholder that had made significant contributions to 2.1 and then
made significant investments implementing it would you have painted yourself into a corner regarding on-going maintenance to the 2.1 work?
I saw Steve Lay’s post about his assumption that the license under which the draft was made available would still allow implementers to continue to use and distribute the 2.1 work. However, as I understand it, that license would prevent derivative works, so maintenance and additions to the 2.1 work independent of IMS would be blocked. Is that correct?
It occurs to me that many standards implementers and stakeholders don’t look at these “fine print” issues prospectively, but they should. I’ve made a couple recent posts to my blog about the need for more uniform, permissive licensing by consortia. As my posts point out, the number and variety open sources software licenses can be a source of much consternation. However, we’re approaching a point where there is more certainty regarding rights under OSS licenses than the licenses granted by consortia and standards orgs. The latter tend to be like snowflakes in that no two are the same.
Pingback: Structured Methods › links for 2009-04-03
WOW v2.1 is a far better format than v1.2, I’ve used both in big assessment projects. I think the issue however is not versions of specifications, its more that “standards” are increasingly irrelevent in the new digital world. The only one that still makes sense is IMS content packaging.
Pingback: Wilbert’s work blog» Blog Archive » IMS QTI and the economics of interoperability