A few weeks back, I went to the first in-person meeting of the IEEE xAPI Base Standard working group. We’re continuing the process of preparing the existing xAPI 1.0.3 specification to submit to a larger audience at IEEE for consideration as a standard. A major tradeoff discussed in that meeting was between avoiding disruptive change, making sure what we standardized would still apply in 10 years, and resolving ambiguities that are unlikely to make it through an IEEE review.
To that end, we decided to look through a set of requirements in 1.0.3 which are marked “SHOULD*” which was our way of saying, “you really, really should do this and you will have to in a later version.” We’re going to clarify each of these to indicate if it is really a conformance requirement or not. Some implementations may have to change when that happens, so if you are on ADL’s list of implementers Andy Johnson will be reaching out to check with you about how these potential changes might eventually impact your implementation. I’m really pleased that we’re going to this effort to understand and minimize impacts on existing adopters, as this effort could have lead to disruptive changes.
We’re also looking at saying less about security and authentication in xAPI, at least in the standard itself. Last time we tried to standardize xAPI, security was one of the concerns that came back from the reviewers. We could try to more thoroughly specify security related behavior in xAPI, but that would have been a big disruptive change which would have invited other big disruptive changes. So we’re going to be considering removing security related requirements from xAPI where possible. We expect that this will allow folks who are happy with how their securing their LRS to continue doing what their doing, and for others to adopt different approaches. There is enough adoption of xAPI with the current security requirements already that they will continue to serve as a “de facto” lowest common denominator for some time. I’ll be leading that effort, so please reach out to me (ben.clark@rusticisoftware.com) if you have input.
So, xAPI is moving along the process of IEEE standardization, and we’re happy with the direction it’s going in. We expect to see more benefits than costs for current adopters. Please do note that this is a slow and painstaking process, so any concrete impacts are a long way out.
If you would like to get involved with any of these groups, you can find contact information here.
Related news:
- The IEEE LTSC xAPI TAG has published a technical report on xAPI which addresses rationale for using xAPI, best practices, and related concerns.
- We’re working with SCORM Renew group to ensure some of the IEEE standards which SCORM is based on are renewed.
