Tincan.xml package metadata

[Plamen Petkov]

Hi all,

First of all, great job RE: TinCan & xAPI, thanks! Awesome!


I have a question/suggestion related to API Versioning, from LRS point of view.

Background:

Run time environment: Apache/PHP/MySQL.

For the purpose of handling 0.9 AND 1.x (separate code base), I was going to use Apache rewrite, based on incoming X-Experience-API-Version header (or the lack of it, for 0.9).

Upon detecting the version, I do an Apache mod-rewrite/redirect to proper code base.

However, "because of IE & Cross Origin", according to specification (v1.0.1, chapter 7.8), there is a special syntax, where headers are NOT part of the HTTP request, but part of POST data (including  the version header).

Now, since Apache does not have access to POST (at least at .htaccess level), there is no way to reliably determine the client version based purely on the request, preventing this otherwise easy mechanic to manage different API versions.


Suggestion for packaged APs

From LRS point of view, at least in the context of E-Learning systems, and again, at least here at Docebo, TinCan's are deployed as packages, following 

http://projecttincan.com/tincan.xsd schema definition. 

My Suggestion is to add xAPI version in tincan.xsd and if not provided, all APs to be considered as version  < 1.0.

This will allow LMS/LRS to store API version along with activity providers upon deployment and later, during AP launch, to specify proper LRS endpoint, based on that very version.



Regards,
Plamen Petkov
http://www.docebo.com

[Russell Duhon]

Hi Plamen,

The first is unlikely to change. Besides being baked in, if we want to use headers for anything (which is a good practice) we have to support burrowing of such headers to support their use in older browsers (*coughIEcough*). Given the die is cast for browser-to-LRS direct communication, that's something sticking around for the foreseeable future.

Re: packaging, the current packaging/launch 'spec', besides not being implemented remotely consistently among authoring tools, has numerous problems, so I wholly support experimentation with new approaches. I'd like to see an informal packaging and launch working group arise; I've been meaning to start one, but I'm fairly busy.

Sincerely,
Russell Duhon
CTO, Saltbox
Makers of WaxLRS

To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.

[Ben Clark]

Hi Plamen,

Making any changes to tincan.xsd or the de-facto launch mechanism seems unlikely.  It's working well enough to gain broad adoption, however CMI-5 is also defining a launch mechanism (based on the existing de-facto launch mechanism). This is generally expected to replace the de-facto mechanism, so there doesn't seem to be a lot of energy to update (and implement updates to) something which is going to be replaced.

So you're probably stuck with using something more flexible than .htaccess to route your requests (or having your administrators specify the version on each package, but that sounds like a big headache).

I encourage anyone concerned with launch and packaging to at least follow the CMI-5 specification work, and ideally join in, since this is currently the only group considering launch and packaging. http://aicccmi5.wikispaces.com/AICC+CMI5+Specification.

Regards,

-Ben

To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.

[brian.miller]

I've had this thought a number of times, also that the launch string should include the version that the LRS is expecting the client to talk. But then I usually remember that ultimately I don't want this because of the /about discovery resource. If version were specified in the package then you would also have to maintain multiple packages, one for each version of the spec which then shifts the burden to the Activity Provider which the spec has always tried to avoid.

As it is currently, the AP can request the best version to use from the LRS(s) that it plans to talk with and so shouldn't have it hard specified in the package for that reason as well. A single package could talk to any 0.95+ LRS using the same language.

Brian

Rustici Software

http://tincanapi.com