search

RusticiSoftware / TinCanJS

JavaScript library for the Experience API (Tin Can API)
http://rusticisoftware.github.io/TinCanJS/
Apache License 2.0
207 stars 115 forks source link

ContextActivities #58

Closed pallu closed 10 years ago

pallu commented 10 years ago

ContextActivites.Parent and ContextActivities.Grouping are arrays in the JS objects. However in the .NET classes (https://github.com/RusticiSoftware/TinCanAPILibraryCSharp), they are objects. Hence when I create a Statement using the TinCanJS and try to deserialize it with the .NET class, it throws an error.

When I changed the .NET classes to have Parent and Grouping as Lists of Activities, I ran into another error. The default "type" for and Activitiy sent by TinCanJS is "course" whereas in the .NET class, it tries to parse it as an Uri and fails.

Is there a way to make the JS and the .NET classes consistent with each other?

brianjmiller commented 10 years ago

The .NET library is behind based on the specification version. In 1.0.0 the context activities properties switched to allow for arrays so this lib has the correct structure and the .NET library needs to be updated. Having said that, it is acceptable based on the spec that when there is only one activity in a given property, for backwards compatibility reasons with 0.95 statement generators, that they could be sent with an object value of a single activity.

TinCanJS doesn't supply a default type for an Activity (Definition), it is null by default. You would only see an Activity Type of "course" if something had passed that type or "http://adlnet.gov/expapi/activities/course" to the library. TinCanJS properly detects specific ADL types and down converts them when sending in 0.9 as 0.9 had specific lists of types for Activities and specific IDs for Verbs. It will only translate the ADL types as they are considered to be analogs and because they were the only acceptable values in 0.9. Any URI may be used in 0.95+, though trying to send a statement with such a value in 0.9 should result in an error from the LRS.

As far as making them consistent, we accept pull requests for both, though in this case it'd be .NET that would need to be updated. As these are OSS libraries while we try to do our best in maintaining and even improving them they don't contribute directly to the bottom line so it is hard for me to give a time frame on when improvements might take place.