The Community Responds

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.


Posted

in

, , ,

by

Tags: