We’re often asked a lot of questions at Rustici ranging from “what is SCORM” to very technical Engine integrations questions. One I was a little surprised to hear being asked in our “office hallways” (aka Slack messages) and beyond is “What is a package?” Turns out, that’s not as straightforward to answer as you might think. Follow me down the rabbit hole into better understanding what a package is and what types of eLearning packages you may run into.
What is an eLearning package?
In the most general sense, a package has something inside of it. Without knowing more, there isn’t much else to say. The more accurate question is what is this package. Usually a package is a .zip file, but not always. With LTI and cmi5, the package may or may not have anything to do with a .zip file. Generally, the “something inside of it” is some metadata or files along with metadata.
What is a manifest?
There are different ways that a manifest can … manifest itself. A manifest is really a list of things that should be contained in the package, but not always. Sometimes manifest files don’t actually include a list of anything that would be in the package. Manifests usually reference some assets that could be included or remotely hosted. For a given piece of content, preferably the contents aren’t both zipped and remotely hosted.
So what is this package?
In the case of non-zip file packages, probably the context will reveal the intent. For instance, the provider of the content will indicate whether it is an LTI tool or a remotely hosted AU for AICC or cmi5. In the case of .zip packages, first, check for a specifically named manifest file. For example, the presence of an imsmanifest.xml file indicates the package is SCORM based.
The manifest will tell a lot about how the package is going to behave and even what we can’t know about how it will behave. There are a number of things that go into the concept of a package that are not well defined or sometimes even within the scope of a standard for that type of package.
Tin Can packages
A Tin Can package is a .zip file with a `tincan.xml` file at its root. Pedantically, that’s about all we can say about what a Tin Can package is. We know this because the concept was introduced via a set of guidelines published with a pre-release version of the Tin Can API. Those guidelines were really just a set of concepts and included very few hard requirements. That’s not ideal from a specification or standard standpoint. A step further, the Tin Can package probably has one launchable content piece inside of it. Meaning, it has one thing it can launch and only one thing it can launch.
That content piece probably expects certain things to be on a query string, but it may or may not use or care about any of them. The content piece likely will speak either Tin Can API, depending on its age, or xAPI in a dialect, and it may communicate that xAPI dialect to an LRS. However, there’s nothing in the Tin Can launch guidelines that says you must use xAPI or do these things.
We can know that we’re going to give it an endpoint, and we’re going to give it a credential. We can’t know whether or not the package is going to do anything with it. There might be assets inside and they need to be served in a certain way. Tin Can provides the option of remotely hosting content that is not in the package. There also might not be any assets in the package at all.
Then what is Tin Can really?
The Tin Can API was a set of guidelines published as part of Project Tin Can that specified a process for capturing and storing data. Our own Ben Clark came up with this ingenious set of guidelines for this new (at the time) specification that was intended to be used to capture all kinds of experiential data that can be stored in an LMS. But there was no consideration about how someone would actually use it. Along with the API itself, there was a set of guidelines about how someone might use it in the LMS context. In other words, how a package might look and how a learner could launch the experience.
We took this set of guidelines meant to start the conversation about how – what would become xAPI – should or could work, ran with it, and marketed them just a little too well. And while the API itself would be further peer reviewed and go through multiple iterations leading to what is now the IEEE standard xAPI, the LMS/launch guidelines languished waiting for something else to take their place.
xAPI packages
The xAPI standard has no mention of a package, and the concept of an xAPI package is essentially meaningless as it doesn’t exist. While authoring tools have an option to publish as an “xAPI package,” it could be anything. A .zip file. A PDF. The standard isn’t specifying a format in terms of what the package is. Having said that, even I’ll admit that the output from authoring tools using the label “xAPI” for export is a Tin Can package with a `tincan.xml` file. And those pieces of content do largely behave like the original guidelines outlined and will usually communicate following xAPI requirements.
cmi5 packages
cmi5 is “the something else to take the Tin Can launch guidelines’ place.” It is a specification, often referred to as an xAPI profile (we’ll save that pedantic debate for another post), that outlines how to effectively use xAPI to capture learning experience data and includes the concepts of packaging content, authorizing a connection to an LRS endpoint, and defining such key concepts as completion, pass/fail, score, and duration (all captured in xAPI statements) in an information model. Unlike xAPI, cmi5 has all the elements of a learning standard and is a nice combination of the aspects that make SCORM the de facto standard and the data tracking abilities of xAPI. If you’re curious to learn more about what makes up a learning standard, check out my “Five Pillars” blog.
As you can tell, “what is a package?” is not always an easy answer, pedantically speaking. But these are the kinds of conversations we have at Rustici every day, so if you have a question about learning standards, packages, or just about anything, we’re happy to chat.
