Support for additional non-standard result parameters

May 26, 2014 at 2:46 PM
I was wondering if the LTI .Net library already supports non-standard result parameters, besides the standard [0,1.0] score.

Example: Let the provider determine if the score was passing: complete=(PASSED|FAILED|UNKNOWN)
1) Provider needs to be able to send it
2) Consumer needs to be able to retrieve it from received outcome service call.
Coordinator
Jun 2, 2014 at 2:32 AM
No it doesn't. The XML parser uses the xsd supplied by IMS...it would not recognize non-standard result parameters. There is an IMS working group looking at revising the results service to support more results. I'll update the library when that reaches a draft status.
Jun 2, 2014 at 8:03 AM
For that reason we would like to use REST and LTI 1.2, so we're not bound to a schema. If we could set additional parameters in the LTI 1.2 outcome service, and get these in the consumer, that would be great. Setting additional parameters in a LTI 1.0/1.1 setting would raise an exception (until IMS has revised their XSD).

If you agree, I could create a patch for inclusion into your code base (as I would rather not fork or write a separate outcome service provider/consumer)

P.S. Additional parameters are needed in a project between several dutch LMS and content/exam providers, hence the interest in this topic...
Jun 3, 2014 at 5:21 PM
See this is one example to prove my point exactly. We are not reinventing the wheel as you say. By not allow to forcing your protocol onto providers it allows for a more flexible system.
Coordinator
Jun 8, 2014 at 5:44 PM
jhabets wrote:
For that reason we would like to use REST and LTI 1.2, so we're not bound to a schema. If we could set additional parameters in the LTI 1.2 outcome service, and get these in the consumer, that would be great. Setting additional parameters in a LTI 1.0/1.1 setting would raise an exception (until IMS has revised their XSD).
The outcomes service did not change in LTI 1.2, it was just separated from the basic launch spec so that the conformance tests could be separated. This will allow people to show conformance to basic launch separately from basic outcomes. Here is the separated basic outcomes spec: http://www.imsglobal.org/lti/ltiv1p2pd/ltiOMIv1p0pd.html. Note that it is the same as LTI 1.1.1 (i.e. still XML).

LTI 2 includes a REST service for results (http://www.imsglobal.org/lti/ltiv2p0/uml/purl.imsglobal.org/vocab/lis/v2/outcomes/Result/service.html). It is still limited to a single decimal value in the range [0, 1]. But there is a lot of discussion going on right now among the members to extend the result service. It should be a lot easier to do with JSON and REST.

If you control (or influence) both the Tool Consumer and Tool Provider in your situation, I think you would be better off ignoring LTI 1.x basic outcomes (which are XML based) and go right to LTI 2 result service. You could implement LTI 1.2 basic launch and LTI 2 result service (REST+JSON) with your own extended results. When the updated result service spec is released it should be pretty easy to merge your custom results with the spec and remain compatible with both your current users and new users.
Jun 10, 2014 at 12:26 PM
Thanks for the answers.

Based on information on developers.imsglobal.org (a.o. LTI 1.2 ... is a subset of LTI 2.0) [1] [2], I was under the impression that the LTI 2.0 REST service would be used for results.

From your answer, and previous answer [3], I gather there are no short-term plans to add LTI 2.0 support, or in particular LTI 2.0 REST result service support to your library. Is that correct?
Would I be able to speed this up by providing you with a patch?

[1] http://developers.imsglobal.org/tutorials.html#id.1fob9te
[2] http://developers.imsglobal.org/tutorials.html#id.2et92p0
[3] https://ltisamples.codeplex.com/discussions/529010
Coordinator
Jun 21, 2014 at 12:43 AM
Yes indeed, a patch would be gladly accepted.