Author Archive

Growing adoption of the Experience API is a core part of what I’m tasked to do around here. Providing high quality, easy to use, open source libraries is one of the best ways I know to do that (aside from writing blog posts, of course!)

The JavaScript library is humming along, our Java clients are happy, and the iOS/Android platforms are well-supported. The natural progression was to knock out a PHP library.MORE…

Deep Dive: Attachments

As network speeds and the processing power of devices improves, the size of the files we use to capture our experiences, be they photos or other graphics, videos, or complex documents, increases. We need a way to associate these ever-growing files with the metadata capturing the rest of the experience. This data comes in all shapes and sizes, particularly these days, and as flexible and readable as JSON is, it isn’t great for capturing large amounts of binary bits, but the Experience API specification allows for including attachments with statements for this purpose.

Attachment handling is implemented through a combination of an ‘attachments’ property of the Statement object itself and optional inclusion of copies of the files themselves. Note the use of plurals here, a single Statement may be associated with multiple files, therefore the ‘attachments’ property of a Statement takes an array as its value. The elements of this array are objects with properties, some required and some optional, that provide metadata about the included attachment.MORE…

A little over a month ago I presented the “Anatomy of a xAPI Statement” webinar as follow up to our continuing Deep Dive series of blog posts. Despite some Q&A time at the end, I didn’t have a chance to answer all the questions, here is the Q&A for that webinar.

A: Several reasons led to its adoption most of which build on the others. At its core JSON is essentially “executable” (technically “evaluatable”) in JavaScript which has led to it being the primary choice for AJAX (or remote requests) in browsers as JavaScript is the single choice for direct browser script execution. The support in browsers has then led to a need on the server side to have good, well established library support in lots of development languages. Because of the common use as a transfer format its minimalist nature was also an important consideration. Finally, it is fairly human readable, certainly relative to XML, but still provides the ability to arbitrarily nest data objects. (See slide #4)

Several times throughout the Deep Dive series I’ve mentioned “catch all” objects and a future post — here it is. The framers of the Experience API specification knew that the overall structure of a statement, particularly with its oft mentioned Actor-Verb-Object pattern, could capture a great deal of information about learning experiences, but they also realized that there was no way for them to account for all types of experiences that people wished to record. So they left an out in the form of ‘extensions’ properties.

These ‘extensions’ properties take a special kind of object where the set of available properties is not known ahead of time, unlike all other objects in the specification. It is this unique structure that leaves it up to the Activity Provider to decide what to capture, and to own how it will be captured.MORE…

So far throughout the Deep Dive series that I’ve been writing, there has been one thing notably lacking, e-learning. It turns out that the framers of the Experience API specification hit on something big enough that it need not be boxed in by just the e-learning world, and so far we’ve seen a lot of adopters thinking outside the typical e-learning sphere. But there is a history there, and the work on the Experience API specification was born out of a real desire to advance the specific space around e-learning. The Result object is there to capture some of what is not already catered for and make sure the Experience API can first, and maybe foremost, flourish in the e-learning space, though even it doesn’t have to be used only for e-learning.MORE…