SCORM is over 10 years old. A while ago, ADL (the keepers of SCORM) asked us to research what the next-generation e-learning specification could/should look like.
We’ve been gathering information from the entire e-learning community about what you’d like to see in the next specification. Many of you already know about this, and many of you have participated.
We have our solution — it’s the Tin Can API.
The Tin Can API solves a lot of problems that older specifications suffered from, but it also adds new capabilities, new business cases, and new ways of handling content. The Tin Can API fuses a decade of collective e-learning experiences with a decade of technological advances.
We’ve created a place for you to go and tell us what we got right and what we missed. Click on the video below to learn more about the Tin Can API.
4 Comments | Post a comment »
Chris Phillips | September 14, 2011 @ 9:59 pm
What is the HTTP response format? It isn’t identified anywhere.
Anonymous | September 15, 2011 @ 1:24 pm
The HTTP content type will be ‘application/json’, when the HTTP response has a body. We envision the format being selectable by the client between at least JSON or XML, but for now have defined the JSON binding only.
Anonymous | September 15, 2011 @ 4:27 pm
It seems reasonable that JSONP should also be an option, as servers that’s barely any work for servers that already have to return JSON.
The LRS at http://api.projecttincan.com is returning “text/plain” in the Contet-Type header. Shouldn’t it be “application/json”?