I hoped in my last post that the community would indeed respond with ideas, insights, opinions and concerns. Thank you for your comments on the post, the retweets and feedback on Twitter and for what I’m sure has been a lot of not-public rumination. The feedback thus far has been incredibly helpful and I will attempt to summarize and then clarify a couple of points.
Most everyone agrees the data model, at the very least, could/should be broken out on its own. In almost every comment on the blog and sentiments shared with me via emails and Skype and instant messages, there’s near universal support for a modular approach to standardization.
Ideas
While we seem to all concur that we’d do well by breaking up the spec into smaller components, there are ideas shared by the community so far that differ from what I posted — specifically on what lines can/should be drawn around different parts of the existing specification.
- A “write-only” API vs. a “query” API.
- A fourth standard to cover retention policy, privacy, protection, access, delegation and security.
- A separation of the Data Model (statement structure and its components) from the Data Binding (JSON), effectively making it possible to work with XML, or other bindings, as an alternative.
- Consider the separation of the spec in terms of the data (JSON), the API (REST)… maybe not specify the LRS at all.
Concerns
There are a couple of concerns that seem to resonate pretty strongly among the community.
- What must be accommodated in terms of privacy and security, at a standards level, is unclear. Use cases representing the various challenges to current implementation of the specification are needed — thinking about the EU, UK, Germany, Australia… California(?). We must also seek out privacy and security laws in other parts. Only then can we specify how to accommodate for the various use cases.
- The current specification group in ADL is a logical group to do the splitting of the specification as it exists today, rather than IEEE which has less representation of the people who developed and have implemented Version 1.0 of the spec. To hand the spec as it is over to another group to perform surgery on it may make for a longer process, whereas the current spec group could accelerate this part of the effort.
Clarifications
I want to again thank you all for the feedback, and if you have more to share, keep it coming. I’ll update this post if there’s more coming.
I agree with the idea that breaking up the current specification doesn’t have to break current implementations. It is certainly not my intent to break what works today. I helped build this with you. I don’t want to see it destroyed… but I’m not going to lie or promise that it won’t break, because it won’t be up to me. If stakeholders in the current xAPI specification group are involved in standardization through IEEE, then they will be the best hedge against breaking current implementations.
I am not tied to the exact divisions of the specification as I laid out in my earlier post. I proposed the divisions because, frankly, a discussion was needed and something to react/respond to is where it starts. I do believe that in some form or other the “statement making” part of the spec needs to be on its own because the use-cases for it are numerous.
I’ll have more to share as appropriate. I wanted to take an opportunity now that the dust has settled a bit to summarize what I’m hearing, to thank you for sharing it, and to encourage you to keep sharing.
I really think the ideas being generated about the modularization of the spec are heading in a positive direction, one that is much more flexible and adaptable than the original.
I especially like the separation of the data model and the data binding; I’m not so concerned with XML but restricting to JSON seemed to be rather short-sighted and limiting; formats like edn and msgpack provide flexibility to APs and content consumers beyond the limitations of JSON, and it should be as simple as managing HTTP “Accept” and “Content-Type” headers to allow for multiple formats.
Decomplecting the statement API from the data model from the data binding from the LRS from the state APIs just makes sense. This could also be an opportunity to deal with some of the (for me) head-scratching curiosities (e.g., that, for instance, the IRI id of a Verb must point to a human-readable (e.g., HTML) representation — why not likewise use “Accept” to make HTML, JSON, XML, whatever representations available and make xAPI more machine-crawlable?).
Modularizing the spec provides a wonderful opportunity to address the logical sub-units of xAPI in isolation and then to determine where the pieces need to interact.
I’m sure this kind of shift in the design process and the spec that results will (since we’re following semver) require the resulting spec to be a 2.0, but it’s better in the long run for the longevity of the spec itself, and for developers who (like me) are sometimes frustrated with tiny aspects of the spec that (sort of) make sense in terms of the whole but could be vastly improved in isolation and then re-integrated while maintaining separation of concerns.