I recently read about the v2 specification, and see it already being drafted. I just thought I'd provide my feedback since there are a few issues with v1 that I feel can provide significant benefits to both xAPI clients and LRS implementors.
As a developer who have implemented an xAPI LRS in two different languages (C# and Dart with a partial implementation in Java) I have encountered the same obstacles in all of them:
[ ] Rename Stament.Object
The paradigm called "Object Oriented Programming" that exist in most of the popular languages implies that EVERYTHING is an Object. This implies that the property needs a different name when not in transit an needs unnecessary logic for serialization/deserialization.
[ ] Avoid ambiguous resource endpoints.
POST Statments accepts both a single or multiple objects. Change this to always require an array. It's easier to count the request than to check if the request is an object or an array.
GET Statements has the same problem: either a single statement or an array can be retrieved. Simply return a Statement Result with one or more Statements in the array since this further complicated when returning an Empty result where the StatementResult has an empty array.
[ ] Move interaction activity properties into extensions.
It makes no sense that interaction activities have conditional properties directly within the definition, when the extensions mechanism can be used. The extensions mechanism works great for other custom activity types, so why would you handle interaction activities differently?
[ ] Avoid Conditional Properties
Serialization performance can be significantly improved by avoiding conditional logic.
It was a nightmare when designing ProtoBuf messages to transport the strongly typed statements.
When using a Relational database to persist the statements, an overly convoluted mapping process has to be implemented to enforce foreign key and required constraints.
The Actor is a great example, where both the Member and IFI properties can be optional or required, depending on not only the ObjectType, but also on existence or absence of the Member property. The simplest solution might be to extract the properties into an Agent and Group object within the Actor.
I really hope you take this into consideration. I really like the possibilities provided by the xAPI and have been using it since 2015, but as a developer I really feel like you never took into consideration the LRS implementation details. The code needed at this stage to implement both an LRS and its clients can be significantly simplified by taking into consideration the issues above.
xAPI Spec Suggestions
I recently read about the v2 specification, and see it already being drafted. I just thought I'd provide my feedback since there are a few issues with v1 that I feel can provide significant benefits to both xAPI clients and LRS implementors.
As a developer who have implemented an xAPI LRS in two different languages (C# and Dart with a partial implementation in Java) I have encountered the same obstacles in all of them:
Stament.ObjectObject. This implies that the property needs a different name when not in transit an needs unnecessary logic for serialization/deserialization.POST Statmentsaccepts both a single or multiple objects. Change this to always require an array. It's easier to count the request than to check if the request is an object or an array.GET Statementshas the same problem: either a single statement or an array can be retrieved. Simply return aStatement Resultwith one or moreStatementsin the array since this further complicated when returning anEmptyresult where theStatementResulthas an empty array.Actoris a great example, where both theMemberandIFIproperties can be optional or required, depending on not only theObjectType, but also on existence or absence of theMemberproperty. The simplest solution might be to extract the properties into anAgentandGroupobject within theActor.I really hope you take this into consideration. I really like the possibilities provided by the xAPI and have been using it since 2015, but as a developer I really feel like you never took into consideration the LRS implementation details. The code needed at this stage to implement both an LRS and its clients can be significantly simplified by taking into consideration the issues above.