Interview with Andy Johnson on Newest Version of xAPI, version 1.0.3

ADL’s previous Community Manager, Craig Wiggins, caught up with ADL Senior Software Engineer and xAPI Spec Group organizer, Andy Johnson to talk about what this release means.

Craig: So, first of all, what’s different about this version?

Andy: So, functionally nothing changes. Due to semantic versioning, all of the 1.0.anythings are all technically the same. So even as we develop an xAPI test suite, if you hear anything about the test suite being 1.0.0 or 1.0.2 or 1.0.3, all of those are functionally the same.

C: This update doesn’t break anything for those who have adopted or who are going to adopt the spec?

A: Exactly. What we do in this version of xAPI is that we get a lot more consistency with terminology. We introduced a couple new terms that are better practices in regards to the rest of the field of computer science and technology. Most of all, we clarify requirements wherever we can so that there aren’t these gray areas that might exist.

C: Can you give us an example of one of these gray areas?

A: Most of the time they have to do with a technology recommendation. Originally we thought that there was no other option – that to make a recommendation was a best practice. Other times it was because the field was moving forward. In the beginning, those technology recommendations were dangerous so in a way . Anybody who knows what they are doing should not be tripped up by them, but the layperson might read that and say “that doesn’t make very much sense,” so we got rid of some of that distraction. There are some requirements – some ‘musts’ – that we have to keep in order to really pinpoint the behavior we were looking for in the original requirement.

C: I noticed that the updated version of the specification seems easier to read from the layperson’s point of view. Was this intentional?

A: Absolutely. We introduced a first section (‘About the Experience API’) which is intended for a layperson to read. They should be able to pick it up, get the terminology of xAPI, and understand it on a conceptual level. There are no requirements in that document – it is intended to foster understanding of xAPI rather than jumping straight into technical details.

C: Is there a particular use case for this section of the spec?

A: Yes. When you think about xAPI, it really returns power to the instructional designer and they don’t need to know all of the gory technical details of the spec. A more advanced instructional designer – especially those who have been around since the early days of SCORM® – are used to understanding the variables or the fields that are out there, so they might jump into the technical sections. The idea was to be able to have an ISD who has read the first section have a conversation with a programmer who has read part two (‘Experience API Data’) and part three of the spec (‘Data Processing, Validation, and Security’) and that conversation should go well. There should be an even exchange of information there. The programmer might have to fill in a few details for the ISD, but they should be able to have a common conversation and exchange of knowledge.

C: Are there any other changes that you’d like to mention?

A: There is one major change in terminology that might be important to the community: ‘activity providers’ are now called ‘learning record providers.’

C: I noticed that. Are you hoping that that will become standard terminology in the community?

A: Right, well yes, we certainly are hoping for that, moving forward. Now, we should be sure to say that the term ‘activity provider’ is still widely used in distance learning. However, what we are hoping to make a certain distinction. When you talk about technical specifications, we’re talking about tracking information, which means that we’re capturing learning records. The entity who provides the learning activity may or may not be responsible for actually tracking.

C: Can you give me an example of how this might work?

A: You can have somebody design an entire course or curriculum and not necessarily know what they want to track. They might hand off to another party to do the tracking. They might even hand off to another tool to do the tracking for them, and just have to feed that tool certain inputs. That tracking tool, then, is the party technically responsible for communication with the learning record store (LRS).

By changing the terminology from ‘activity provider’ to ‘learning record provider’, we’re taking the responsibility away from the content developer (and thus the activity provider) and we’re putting it where it belongs technically – with that entity which is creating the actual code to send the experience data to the learning record store.

C: What are the xAPI spec group’s plans after the release of xAPI 1.0.3?

A: What we’re hoping to do is take a long hiatus on versioning these ‘dot’ versions because there shouldn’t really be anything left. We’ve taken our time on releasing this one, so we’re hopeful that that’s taken care of all of the minor issues. Eventually – as technology keeps moving – we’ll see a push to create an xAPI version 1.1. We do have our lists of things that we do want to change [in the spec] for 1.1 or 2.0, but right now there’s nothing pressing enough that would cause us to move in that direction. You know, there are things with consistency, with timestamps, looking at new technologies that mature, etc. We might want to make a move at some point, but right now – considering both the early adopters and the regular adopters – there [currently] isn’t a reason to change the spec on them just for these few [minor items].

You can see the newly-minted specification version on ADL Initiative’s GitHub xAPI project.