Today the eLearning specification xAPI turns 10. It’s even longer since, as part of “Project Tin Can,” I created the draft “Tin Can” specification which xAPI is based on. With the birthday and the announcement of xAPI 2.0 becoming an IEEE standard, I can’t help but reflect on how far the specification has come and think about the future.
Before xAPI: Tin Can
The goal of Tin Can, which I did for Rustici Software under contract from the ADL, was to come up with a more modern successor to SCORM. As I sought input on what this SCORM successor needed to do, I kept hearing that people wanted to be able to get at their data. Other requests included keeping it simple, support for non-launched and non-browser learning experiences, and an expanded set of what it’s possible to track.
While there was excitement about being able to track learning experiences without a launch (such as a CPR dummy), we still saw the need for some way to package and launch content. So I also quickly drafted “Incorporating a Tin Can LRS into an LMS” as a placeholder until the community could come together on a better launch and packaging mechanism, with the solution now being cmi5. Since then every “Tin Can” or “xAPI” launch has used the process described in that draft.
10 years of xAPI
When I think about the past 10 years, I can’t help thinking about my son who is also 10. He has grown so much over the past decade, and while xAPI itself hasn’t changed much, its usage has certainly evolved.
One of the key problems xAPI tried to solve was “I want to get at my data,” and looking back it’s where it has been most successful. It is now possible to collect learning data in a Learning Record Store (LRS) and make it available to an external reporting or analytics platform. There is a learning curve to get this right, but many organizations are taking advantage of this ability every day. This is made possible by the concept of the immutable learning record (statement) and support for querying those statements as part of the specification and the test suite.
Other xAPI features haven’t fared as well. Activity and Agent Profile resources are tricky to provide access to in a way that is both secure and useful, so they are mostly unused. I’m most personally disappointed I don’t hear more about people using attachments, including signed statements. The ability to include a certificate or learning evidence tied to a statement – and have that signed – seems important to trusting the assertions moving from one system to another in the form of statements, but in practice a model of the receiving system just trusting the sender seems to be used. As more systems generate statements that model may break down, and the ability to sign statements will be there to help. xAPI has been used for some non-launched experiences, but we still mostly see launched content, generally using “Tin Can” launch.
New xAPI, (mostly) same as the old xAPI
On March 30th, IEEE approved “IEEE 9274.1.1-2023” the “IEEE Standard for Learning Technology— JavaScript Object Notation (JSON) Data Model Format and Representational State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access,” AKA xAPI 2.0.
The big deal here is who has approved it. Being an IEEE approved standard puts xAPI in the same category as other standards we rely on, like Wi-Fi (IEEE 802.11).
The biggest change is a new way to associate agents in statement context, similar to the existing “context activities”. Besides that, various strong recommendations in 1.0 are requirements in 2.0, and many edits for clarity have been made. People are still going to be doing the same things with it they’ve been able to do for the past 10 years, and we don’t expect a fast switchover.
For content authors and authoring tool vendors, you can’t interoperably launch xAPI 2.0 yet. You should wait for cmi5 to support 2.0, including anyone using “Tin Can” launch, who should plan on switching to cmi5 when they go to 2.0. We’re pushing towards getting 2.0 support into cmi5, but there is really no need to rush on the content side.
Anyone doing analytics should get ready to support 2.0 sooner, which will be easy to do given the minor changes involved. 2.0 can be implemented with backwards compatibility, and we can’t know exactly when it will be adopted on the content side – so it makes sense for anyone consuming xAPI data to adopt 2.0 sooner than later. Still, with no interoperable launch mechanism, it’s going to take a while for the content side to get there.
In 10 years, my son has grown a lot, but in the world of eLearning standards, things change at a slower pace. It’s great to see how widely adopted xAPI has become in this time, and now to see it all grown up with IEEE approval. I look forward to seeing cmi5 replace “Tin Can” launch and all the uses people find for xAPI over the next 10 years.
