Contact Us Support Forum Get Email Updates

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Experience API questions:


Author Archive

Names and domains

Posted by

Categories: News

Posted 5 March 2018


In the middle of last year, I made explicit a transition we at Rustici Software made, moving from the name Tin Can API to Experience API, or more frequently, xAPI. Coincidentally, we started redirecting web traffic from to

And this spring, we’re in the midst of substantially reconstructing our various websites (, and A part of this will be making the home of all things commercial, leaving the and websites as primarily community resources.

As a part of this transition, we have moved to, because who doesn’t prefer a four letter domain name? For reasons that are somewhat beyond me, that transition works better if we change the domain prior to changing the websites themselves. So, welcome to step one of the transition, where will now be We’ll handle the redirects, etc, so you shouldn’t have to do anything differently at all. We’ll have further content changes for you over the next several months.

No Comments

Political intrigue. High stakes drama. Inside baseball. This post is about something that is important but not exciting.


Facts: Next week, the IEEE LTSC xAPI TAG will be taking a vote about if and which aspects of xAPI 1.0.3 to propose to the broader IEEE for consideration as a standard.

Opinions (mine):

  • Somewhat important: standardization matters in that many organizations (particularly some outside the US) will care that xAPI has (eventually) been blessed by IEEE.
  • More important: the nexus of xAPI work is moving toward this group, and it’s active.

I’m firmly amongst the xAPI pragmatists, seeking shorter term gains and use cases where xAPI is legitimately better than other solutions. This active group, the TAG, is crucial in that it will be able to explore and innovate allowing the utility of xAPI to grow beyond what is currently well supported. Simply, xAPI and its supporting technologies are already useful but not yet sufficient for everything people hope it can be. The work matters, and it needs a home. This seems to be that home.

The Details

The details come with full credit to Shelley Blake-Plock and Avron Barr for their clarity and content.

  • The TAG is considering multiple potential standards related to xAPI 1.0.3, ranging from xAPI data model and bindings to profiles, conformance and LRS behaviors.
  • Members of the TAG will write Project Authorization Requests (PARs) for each proposed standard, delineating purpose, need and scope.
  • PARs will then go through the IEEE approval process over a period of several months and steps.
  • Working groups may begin work prior to that formal approval in the LTSC, based on the assumption that the PARs pass.
No Comments

The continuum of xAPI questions at ATD TechKnowledge

Posted by

Categories: Events, News

Posted 29 January 2018


Just a quick note as I head from ATD TechKnowledge in San Jose to Learning Technologies in London…

TechKnowledge was a good event this year. I enjoyed presenting with Margaret Roth of Yet Analytics and Megan Torrance of Torrance Learning at the xAPI Showcase, where we shared examples of what people are doing with xAPI. We used xapiapps to survey the audience about our presentations and three different LRSs (Watershed, Yet and SCORM Cloud) to compile the survey data. That provided a good representation of how to connect different xAPI platforms and the differences between LRSs.

It was fascinating to see the variety of questions in the xAPI space these days. We had good questions about the basic players like, “What’s a learning record store and what’s a learning record provider?” And we had good questions about the underlying technologies employed by LRS vendors like, “Are they using NoSQL solutions or traditional databases? And what’s preferable?” On a continuum, these questions are at opposite ends. But they came within moments of each other. Trying to modulate the answers for an audience so diverse really keeps you on your toes.

My thoughts on these questions…

In regards to the difference between a learning record store (LRS) and learning record provider, who knew the word “store” would be so confusing? It makes sense to me now, particularly in the context of the “App Store” that we instinctively think of the learning record store as a place to buy things rather than a place to keep them.

As for the question about using NoSQL solutions or traditional databases, both kinds of data stores have their place. And some providers are actually using both. But there is no simple, clear, right answer as to which is better. And xAPI (the specification) shouldn’t have an answer to it. Technologists can though.

Overall, I really liked the slightly calmer vibe at TechKnowledge. There is a little more space for nuanced conversation with people and that was helpful to me.

No Comments

Mea culpa

Posted by

Categories: Announcements, News, Spec Effort, xAPI

Posted 8 December 2017


I’m sorry. My bad. Mea culpa.

I wrote this all the way back in September, and I told you I’d follow it up with a further post one week later. It’s now eleven weeks and one day later and I still don’t have an answer for you. To be honest, I am struggling to discern which pieces of work would best support the xAPI community and Rustici Software. We’re talking about it here frequently, and haven’t reached consensus. And for that reason, I’m not making commitments and we’re not starting the process of building anything yet.

We’re active, yes. There’s good work happening at the IEEE LTSC TAG xAPI, and we’re doing a bit of it. And ADL has published new BAA requests, and we’re considering those. But mostly, we’re patient. We’re thinking through what we could build and if it’s the best use of our energies.

So, for the time being, please accept my apologies for naively predicting I would have something conclusive to say a week later. I’ll keep trying.

No Comments

Part One: How We Decide to Do Work

Posted by

Categories: Ideas, Spec Effort, Standards, xAPI

Posted 21 September 2017


A couple of days ago, I wrote about the state of ADL and Rustici Software’s take on it. One of the real community leaders, Aaron Silvers, then shared his perspective, partially in response. If you read them both, you’ll see some overlap and gaps in our responses, but the thing I want to address is that it seemed Aaron was asking a question or making a request of me (Tim?) or Rustici Software in the process.

Important note for those unfamiliar with this space: I work at Rustici Software, a for-profit software company. Since we started working with standards in 2003, we’ve been active within the community and try to build software that spares customers having to deal with the standards. This website, like before it, is how we interact with and provide resources to that community.

Aaron may not have been asking these questions, but in order to answer his, I have to explore two questions:

  • How does Rustici Software decide to do work?
  • How does Rustici Software decide which work to do?

How we decide to do work

There are two kinds of work that are clear yeses for us.

  • Work that serves two or more other organizations well enough that they’ll pay us enough to justify the work.
  • Work that we can do now because it helps us do our jobs better.

Number one might be pretty obvious to you. This is the essence of a products company.

Number two is a little less obvious, but just as true. Back in the SCORM days, one of the fundamental problems was that it was simply tough to tell what was going on when a LMS launched a piece of content. As good developers do, the venerable Mike Rustici added debugging tools so he could see what was going on. (Keep in mind, this was way back in the days prior to good debugging tools being built directly into the browsers.) Mike was solving a problem he had, but he quickly saw the broader utility of those debugging tools.

We listed that debugging log as a top feature of SCORM Engine from day one. We also decided that it was worth sharing with the world. We wrapped a little bit of code and interface around our core product (SCORM Engine), labeled it SCORM Test Track, and shared it. It’s been subsumed by SCORM Cloud now, but that capability brought thousands of people to Rustici Software and introduced them to things that we do well.

Those debug logs, and Test Track, have had real, lasting, positive impact, for both the community and for us at Rustici Software. If we’re going to do work that fails at number one (making money directly), then we want to have an impact.

ADL’s guiding hand

For most of the last 15 years, ADL has been the primary organizing force in the corporate elearning standards space. This force is realized in two ways:

  • ADL funds research of a specific type, with specific organizations, which causes things to happen to the eLearning standards.
  • ADL decides what is in – in scope, in the spec, in the agenda for the specification meetings. This is mostly good, because a community needs organization and leadership.

This had led to real and important work. Project Tin Can was a successful initial effort on our part, funded entirely by ADL, that led to what you now know as xAPI. Similarly, ADL funded the work that DISC did in 2016-2017 that led to an xAPI profile definition specification. This money from ADL provided incentive, and ADL’s guidance provided direction.

ADL has served as the arbiter, allowing certain things to become a part of the core xAPI specification, and pushing others into other areas (cmi5, for example). They also made decisions about which community projects to highlight, which ones to work from.

Our rules about taking work are somewhat different with regard to standards bodies. On multiple occasions over the last 3 years, work that Rustici has done and offered to the community in various ways (OSS or hosted service) has been passed over or recreated. This includes:

What should we do from here?

So here’s the crux of it: Based on the current budgetary environment in the US, ADL does not currently have the ability to fund additional research, nor do they have a large number of resources to do work in house. They have retained, however, their position of authority; they decide what’s in, or they do until they don’t.

At some point, we had to start asking ourselves this question: If ADL doesn’t explicitly approve work we’re doing for community use ahead of time with their funding, does it serve us or anyone for us to take on big chunks of work like this? Simply, under what circumstances are we willing to do work to support the community without being paid?

So I have a question for the community… for you, the reader who trudged through just this many words. If we stand up an xAPI Profile Server and a service to test for valid, well-structured xAPI Profiles, on our servers, evolving it at the pace and in the manner we see fit based on the problems expressed to us by our customers and the community, will you use it? Would you allow us to play a significant, central role in that way? And to ADL, would you approve of that?

My sense is that the community would like for us to build these things, but only under very specific conditions.

OK. I’m about 1000? words into a post and I’ve answered one question. But I’m going to stop here. The answer to this one precedes the answer to the second: How does Rustici Software decide which work to do? We’ll come back to that one in a post we publish next week.* Until then, let us know if you’re open to using tools that we build.

* Update: We are still pulling together our thoughts on which work we plan to do based on conversations with standards folks and our own internal team. This is coming, it’s just going to take a little longer than we thought. 

Have a more nuanced response? Email it to us: