Sponsored by the Office of the Under Secretary of Defense for Personnel and Readiness (OUSD P&R) Experience API (xAPI) Update Andy Johnson Contractor with Problem Solutions, LLC in support of the ADL Initiative I/ITSEC Plugfest 3 December 2014 Orlando, FL

History 2 ‣ xAPI transitioned to ADL in 2012 as version.80 of what was called “TinCan” ‣ At this point in time the working group was established, releasing.95 in October 2012 and 1.0 in April 2013 ‣ Version was formalized and released in Oct 2013 (clarification and intended 1.0 changes only) ‣ Informal and (no breaking changes)

Today 3 ‣ xAPI has been stable (no huge changes) for 18 months ‣ Technical language in the spec is getting more and more specific (to stop bad practices) ‣ Technical Working Group meets weekly to work out issues ‣ Many other groups, ADL and otherwise, meet to create profiles, define verbs, create xAPI activities, templates, tools, and examples

Divide and Conquer 4 ‣ Important to have “in scope” and “not in scope” conversations: ‣ Technical Writing Specifciation Group ‣ Targets version ‣ Issues originate on GitHub ‣ Implement requirements and best practices ‣ All changes in scope ‣ Use Case and Implementation Group ‣ Targets version 2.0 ‣ Use cases presented on and discussed in meeting ‣ Ideas based on merit, not “how much it will break things”

Version ‣ Working Group is editing technical specification requirements to be as clear as possible ‣ Spec requirements feed into Conformance Testing (more of a private effort until all requirements are redone) ‣ Also adding best practices, some of which the group has agreed will become requirements in version 2.0 ‣ Maintaining backward compatibility for “good” implementations

Version Goals 6 ‣ Further define the Sub-APIs of the document ‣ State API ‣ Activity/Activity Profile ‣ Agent Profile ‣ Split out and further define the Learning Record Store role ‣ Currently intertwined with the rest of the document, not clear responsibilities ‣ Enables modularization of spec for potential standardization (suggested by IEEE) ‣ Decide on the role of the spec in regards to Privacy and Security ‣ Separate section or separate document?

Version Current Issues 7 ‣ RESTful nature of xAPI ‣ xAPI adopts many REST best practices, but isn’t truly REST ‣ Verbs and the use of identifiers ‣ An identifier can human-readable, but cannot be used in semantic web or AI systems ‣ Data synchronization ‣ Pagination ‣ Voiding Statements and timing ‣ Cannot expand Statements other than “extensions”

Time Stamps 8 ‣ xAPI has time stamps for everything, but doesn’t have any teeth towards how offsets should be used ‣ A user in Washington D.C. could finish 3 hours earlier than someone in Seattle, when in reality, it is the same time ‣ Huge headache for reporting team training/learning scenarios ‣ Suggesting all systems store as UTC +0, can report to individual time zone if desired

O-Auth ‣ xAPI defines how to use O-Auth 1.0, not a requirement of a system ‣ xAPI uses parts of O-Auth 2.0 in other areas, but doesn’t define it ‣ Discussion of if xAPI should expand to talk about O-Auth 2.0 (Facebook, Google, Twitter, etc. use it) ‣ Issue is that a very strong profile for 2.0 would be needed, whereas 1.0 is very generic ‣ Have had volunteers to try to write such a profile

Andy Johnson Advanced Distributed Learning (ADL) Resources: xapi.adlnet.gov xapi.adlnet.gov