Simple Outcomes

[Scott Wilson]

Hi Chuck & IMS-Dev'ers,

Wilbert and I had a look at the draft for Simple Outcomes and given it some thought. We both think its definitely a step in the right direction and somewhere we should focus more effort. 

Below are some of our initial comments on things we think could be clarified or simplified.

1. Model

=======

I guess I'm unclear about what the relation is between a tool and result. Does the tool have a single result object in the container, and we just update it, or is there an array of results and we have to be careful which ones we PUT? I've assumed the latter, but the former would considerably simplify matters if it fits the 80% case.  Wilbert's reading of it is that it is very clearly a single result, so clearly there is some room for interpretation here that needs clarifying.

Wilbert also is strongly in favour of presenting the simplest possible solution and then waiting for people to start demanding extra capabilities, and I think that's probably the best approach. It also clearly differentiates SO from full LTI and full LIS.

2. Launch parameters.

=================

There are really only two things of interest - where is the results URL, and what token do I use? I don't think the resultvalue_sourcedids is all that useful.

I think also the term "result_sourcedid" may be confusing; how about just "result_token" to make the point this is an internal opaque identifier and not actually an Id? SourcedId in IMS specs is usually intended for exposing "real" keys. It could also get confused with the ID you'd have to use to update a result. 

3. Messages

==========

This is kind-of-pseudo-RESTful; we suggest using REST verbs instead of message types parameters.

We need to be careful of the semantics of GET - is the intention that this is limited to the scope of result(s) that are created by the tool? In which case isn't it redundant if the tool persists results itself? I can imagine it might be handy if you want really simple tools that don't persist their own results - is that a likely enough case to need a specific method?

In terms of parameters, as the context has already been given by the launch using a token, it should not be necessary to provide a person id as well - if we assume the token is keyed to a specific instance of a tool for a specific user, rather than just the launch context.

If supporting update and delete, you also need to have a resource associated with the created result. At first I thought this was "sourcedId" in the response, but that could be interpreted to be an echo of the result token (and a good reason not to use the term sourcedId when we really mean a token). 

Again, this is somewhere where the possible interpretation of single or multiple results caused some confusion when Wilbert and I compared our interpretation, so I won't go any further here until we've sorted that out.

Datasource would also seem redundant if the token is generated keyed to the tool; the datasource should be the tool itself.

To keep things simple Wilbert and I suggest making nearly everything optional with defaults. E.g.:

lti_version optional; default=latest version

lti_message_type (if still used) optional; default = simple-lis-createresult

result_statusofresult optional; default=unmoderated

result_date optional; default= time of request

result_resultvaluessourcedid optional; default=decimal

So a valid request to create a score would be:

POST {ext_ims_lis_simple_outcome_url}

result_token=23432423bc221ff1450

result_resultscore_textstring=0.8

201 CREATED

<simpleoutcome>

<lti_message_type>simple-lis-readresult</lti_message_type>

<result>

  <sourcedid>123456</sourcedid>

  <statusofresult>unmoderated</statusofresult>

  <date>2010-07-18T10:55Z</date>

  <resultscore>

    <resultvaluesourcedid>decimal</resultvaluesourdedid>

    <textstring>0.8</textstring>

    <language>en-US</language>

  <resultscore>

</result>

</simpleoutcome>

And to update:

PUT {ext_ims_lis_simple_outcome_url}/123456

result_token=23432423bc221ff1450

result_resultscore_textstring=0.9

4. Response format

===============

Can we use HTTP status codes rather than the IMS Statusinfo?  I shouldn't really need to parse the message content if its a 2xx and I don't do updates or deletes. (We only created StatusInfo in IMS for use with SOAP, especially cases where there are multiple batched operations in a single request.)

====

Anyway, we hope this is useful - we've already started talking to projects and institutions here in the UK about SimpleOutcomes as we think its definitely one to watch.

Cheers,

S (& W)

[csev]

Thanks Scott and Wilbert -  commentary inline.

On Sep 23, 2010, at 4:31 AM, Scott Wilson wrote:

1. Model

=======

I guess I'm unclear about what the relation is between a tool and result. Does the tool have a single result object in the container, and we just update it, or is there an array of results and we have to be careful which ones we PUT? I've assumed the latter, but the former would considerably simplify matters if it fits the 80% case.  Wilbert's reading of it is that it is very clearly a single result, so clearly there is some room for interpretation here that needs clarifying.

As written there is a single result per resource_link_id - there is not an array of results.  Effectively a tool launch gets a column in the gradebook - much like any Moodle Activity gets a column in the grade book.   A Basic LTI launch is like Moodle Activity.   The key is for one activity there is not an array of results.

If you look a the IMS LIS spec this is based on, the data model is a single grade + a bag of key/value pairs.  I chose not to include the support for key/value pairs in SimpleOutcomes but am seriously considering adding it if this evolves into a more complete "Basic LIS" formal specification.

Wilbert also is strongly in favour of presenting the simplest possible solution and then waiting for people to start demanding extra capabilities, and I think that's probably the best approach. It also clearly differentiates SO from full LTI and full LIS.

Yes - the simplest that is sufficient for a reasonable part of the problem space. 

2. Launch parameters.

=================

There are really only two things of interest - where is the results URL, and what token do I use? I don't think the resultvalue_sourcedids is all that useful.

I am on the fence - LIS has this and I just borrowed it.   Really, I think it is probably better to have this flexibility, knowing that only the decimal will be implemented for the first few years.   We need to be really explicit telling tools not to expect lots of choices here.

I think also the term "result_sourcedid" may be confusing; how about just "result_token" to make the point this is an internal opaque identifier and not actually an Id? SourcedId in IMS specs is usually intended for exposing "real" keys. It could also get confused with the ID you'd have to use to update a result. 

It is a token - but the terminology is directly from LIS and is already in the approved Basic LTI spec.

3. Messages

==========

This is kind-of-pseudo-RESTful; we suggest using REST verbs instead of message types parameters.

I will hold off 20 pages of commentary here :)  My goal was not to be "maximally restful" but instead to be practical and easy to implement, borrowing from REST but maintaining alignment with IMS LIS data models.  And yes, I know IMS data models have a bit of RPC baked in at the lowest level - for me I just accept that fact.  If LIS did not recast itself as REST, Basic LIS probably won't either.   It is very nice to remain a binding rather than a new and parallel and slightly bent base document.

We need to be careful of the semantics of GET - is the intention that this is limited to the scope of result(s) that are created by the tool? In which case isn't it redundant if the tool persists results itself? I can imagine it might be handy if you want really simple tools that don't persist their own results - is that a likely enough case to need a specific method?

Well - the result_sourcedid points to a cell in the grade book - it seems logical to simply define CRUD operations in the spec and then let the implementations worry about things.  One advantage of GET is privacy - a tool can make a claim that they don't "retain" any grades - they may at times pull them down and then update them but never persist them in some "yucky" US-based cloud service.  It is not airtight logic - but it is a gentle rationale nonetheless.

In terms of parameters, as the context has already been given by the launch using a token, it should not be necessary to provide a person id as well - if we assume the token is keyed to a specific instance of a tool for a specific user, rather than just the launch context.

Yes - This probably should be removed - I took it from LIS - but really this is a bit different use case.

If supporting update and delete, you also need to have a resource associated with the created result. At first I thought this was "sourcedId" in the response, but that could be interpreted to be an echo of the result token (and a good reason not to use the term sourcedId when we really mean a token). 

In a sense, the result_sourcedid is not something that the tool can create at all.   So perhaps there should be no C in CRUD for this ...  Hmmmm.   Good point.

Again, this is somewhere where the possible interpretation of single or multiple results caused some confusion when Wilbert and I compared our interpretation, so I won't go any further here until we've sorted that out.

Single result but many LMS's keep every "store" in history - that is outside of the scope of this API - this API can only see the "current/latest/only" value and has no access nor control over how the LMS handles update logs.

Datasource would also seem redundant if the token is generated keyed to the tool; the datasource should be the tool itself.

This makes sense.

I like this in general.  I do like some parameters that give a bit of a "message signature" - but at the same time dropping in lots of default redundant stuff is kind of silly.   Lets revisit this if/when Basic LIS starts up.

4. Response format

===============

Can we use HTTP status codes rather than the IMS Statusinfo?  I shouldn't really need to parse the message content if its a 2xx and I don't do updates or deletes. (We only created StatusInfo in IMS for use with SOAP, especially cases where there are multiple batched operations in a single request.)

This is an attempt to stay "binding like" and keep it is thin and direct as possible to reduce debate.  I agree that this is something to be debated and discussed a bit more - particularly as IMS moves toward non-SOAP message approaches.

My position in that debate - subject to seeing something better - is that I would rather error information + detail be in the message than in the error codes because it means it is more easily implementable in lots of languages.

If you did not like parsing XML to find the error message, I would almost prefer both an XML and JSON binding of the responses rather than sliding critical information into the response header.

This of course is a "many-pint" debate to get to resolution. :)

Anyway, we hope this is useful - we've already started talking to projects and institutions here in the UK about SimpleOutcomes as we think its definitely one to watch.

Thanks - SimpleOutcomes is a cool experiment and nice to play with something as a run-up to a real specification in this space which I hope to launch at the IMS Meeting in November - I want to call it "Basic LIS" :)

/Chuck

[Scott Wilson]

On 23 Sep 2010, at 13:57, csev wrote:

Thanks Scott and Wilbert -  commentary inline.

On Sep 23, 2010, at 4:31 AM, Scott Wilson wrote:

1. Model

=======

I guess I'm unclear about what the relation is between a tool and result. Does the tool have a single result object in the container, and we just update it, or is there an array of results and we have to be careful which ones we PUT? I've assumed the latter, but the former would considerably simplify matters if it fits the 80% case.  Wilbert's reading of it is that it is very clearly a single result, so clearly there is some room for interpretation here that needs clarifying.

As written there is a single result per resource_link_id - there is not an array of results.  Effectively a tool launch gets a column in the gradebook - much like any Moodle Activity gets a column in the grade book.   A Basic LTI launch is like Moodle Activity.   The key is for one activity there is not an array of results.

If you look a the IMS LIS spec this is based on, the data model is a single grade + a bag of key/value pairs.  I chose not to include the support for key/value pairs in SimpleOutcomes but am seriously considering adding it if this evolves into a more complete "Basic LIS" formal specification.

Wilbert also is strongly in favour of presenting the simplest possible solution and then waiting for people to start demanding extra capabilities, and I think that's probably the best approach. It also clearly differentiates SO from full LTI and full LIS.

Yes - the simplest that is sufficient for a reasonable part of the problem space. 

OK, that all sounds good to me!

2. Launch parameters.

=================

There are really only two things of interest - where is the results URL, and what token do I use? I don't think the resultvalue_sourcedids is all that useful.

I am on the fence - LIS has this and I just borrowed it.   Really, I think it is probably better to have this flexibility, knowing that only the decimal will be implemented for the first few years.   We need to be really explicit telling tools not to expect lots of choices here.

I think also the term "result_sourcedid" may be confusing; how about just "result_token" to make the point this is an internal opaque identifier and not actually an Id? SourcedId in IMS specs is usually intended for exposing "real" keys. It could also get confused with the ID you'd have to use to update a result. 

It is a token - but the terminology is directly from LIS and is already in the approved Basic LTI spec.

OK, that's fair enough - with the clarity on the model side of things it becomes less of an issue anyway.

3. Messages

==========

This is kind-of-pseudo-RESTful; we suggest using REST verbs instead of message types parameters.

I will hold off 20 pages of commentary here :)  My goal was not to be "maximally restful" but instead to be practical and easy to implement, borrowing from REST but maintaining alignment with IMS LIS data models.  And yes, I know IMS data models have a bit of RPC baked in at the lowest level - for me I just accept that fact.  If LIS did not recast itself as REST, Basic LIS probably won't either.   It is very nice to remain a binding rather than a new and parallel and slightly bent base document.

We need to be careful of the semantics of GET - is the intention that this is limited to the scope of result(s) that are created by the tool? In which case isn't it redundant if the tool persists results itself? I can imagine it might be handy if you want really simple tools that don't persist their own results - is that a likely enough case to need a specific method?

Well - the result_sourcedid points to a cell in the grade book - it seems logical to simply define CRUD operations in the spec and then let the implementations worry about things.  One advantage of GET is privacy - a tool can make a claim that they don't "retain" any grades - they may at times pull them down and then update them but never persist them in some "yucky" US-based cloud service.  It is not airtight logic - but it is a gentle rationale nonetheless.

In terms of parameters, as the context has already been given by the launch using a token, it should not be necessary to provide a person id as well - if we assume the token is keyed to a specific instance of a tool for a specific user, rather than just the launch context.

Yes - This probably should be removed - I took it from LIS - but really this is a bit different use case.

If supporting update and delete, you also need to have a resource associated with the created result. At first I thought this was "sourcedId" in the response, but that could be interpreted to be an echo of the result token (and a good reason not to use the term sourcedId when we really mean a token). 

In a sense, the result_sourcedid is not something that the tool can create at all.   So perhaps there should be no C in CRUD for this ...  Hmmmm.   Good point.

Again, this is somewhere where the possible interpretation of single or multiple results caused some confusion when Wilbert and I compared our interpretation, so I won't go any further here until we've sorted that out.

Single result but many LMS's keep every "store" in history - that is outside of the scope of this API - this API can only see the "current/latest/only" value and has no access nor control over how the LMS handles update logs.

So its not totally RESTful but partly this isn't an issue as it isn't really CRUD either :)

Each sourcedId is associated with exactly one result resource; it is a prerequisite that this resource exists when the service is invoked (though the actual lifecycle is up to the TC). A tool can't create or delete the result resource - they can just read the value of the result resource, or update it with a new value ("delete" is more like "clear" or "reset").

Datasource would also seem redundant if the token is generated keyed to the tool; the datasource should be the tool itself.

This makes sense.

To keep things simple Wilbert and I suggest making nearly everything optional with defaults. E.g.:

...

I like this in general.  I do like some parameters that give a bit of a "message signature" - but at the same time dropping in lots of default redundant stuff is kind of silly.   Lets revisit this if/when Basic LIS starts up.

Sure.

4. Response format

===============

Can we use HTTP status codes rather than the IMS Statusinfo?  I shouldn't really need to parse the message content if its a 2xx and I don't do updates or deletes. (We only created StatusInfo in IMS for use with SOAP, especially cases where there are multiple batched operations in a single request.)

This is an attempt to stay "binding like" and keep it is thin and direct as possible to reduce debate.  I agree that this is something to be debated and discussed a bit more - particularly as IMS moves toward non-SOAP message approaches.

My position in that debate - subject to seeing something better - is that I would rather error information + detail be in the message than in the error codes because it means it is more easily implementable in lots of languages.

If you did not like parsing XML to find the error message, I would almost prefer both an XML and JSON binding of the responses rather than sliding critical information into the response header.

This of course is a "many-pint" debate to get to resolution. :)

I think including detailed error information in the response is a good thing (e.g for logging), but its useful to have the HTTP status codes returned as these tend to be handled by the code libraries used to make the request anyway.

So a compromise position would be to keep the IMS status info XML, return it in the response body, but have the response header contain a useful HTTP status code and not just 200 for everything. It may be IMS, but its still the web!

Anyway, we hope this is useful - we've already started talking to projects and institutions here in the UK about SimpleOutcomes as we think its definitely one to watch.

Thanks - SimpleOutcomes is a cool experiment and nice to play with something as a run-up to a real specification in this space which I hope to launch at the IMS Meeting in November - I want to call it "Basic LIS" :)

That could be even more of a many-pints debate than REST v SOAP/RPC :-)

/Chuck

--
You received this message because you are subscribed to the Google Groups "IMS Developer Mailing List" group.
To post to this group, send email to ims...@googlegroups.com.
To unsubscribe from this group, send email to ims-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ims-dev?hl=en.

[csev]

On Sep 23, 2010, at 9:49 AM, Scott Wilson wrote:

On 23 Sep 2010, at 13:57, csev wrote:

We need to be careful of the semantics of GET - is the intention that this is limited to the scope of result(s) that are created by the tool? In which case isn't it redundant if the tool persists results itself? I can imagine it might be handy if you want really simple tools that don't persist their own results - is that a likely enough case to need a specific method?

Well - the result_sourcedid points to a cell in the grade book - it seems logical to simply define CRUD operations in the spec and then let the implementations worry about things.  One advantage of GET is privacy - a tool can make a claim that they don't "retain" any grades - they may at times pull them down and then update them but never persist them in some "yucky" US-based cloud service.  It is not airtight logic - but it is a gentle rationale nonetheless.

Again, this is somewhere where the possible interpretation of single or multiple results caused some confusion when Wilbert and I compared our interpretation, so I won't go any further here until we've sorted that out.

Single result but many LMS's keep every "store" in history - that is outside of the scope of this API - this API can only see the "current/latest/only" value and has no access nor control over how the LMS handles update logs.

So its not totally RESTful but partly this isn't an issue as it isn't really CRUD either :)

Each sourcedId is associated with exactly one result resource; it is a prerequisite that this resource exists when the service is invoked (though the actual lifecycle is up to the TC). A tool can't create or delete the result resource - they can just read the value of the result resource, or update it with a new value ("delete" is more like "clear" or "reset").

Yes, I agree that it is not really CRUD since the TP cannot create it, and it is unclear if TP must call create before it calls update - and you can see this confusion in the existence of "simple-lis-replaceresult" which is a "create/populate/replace" as appropriate.  Seems like a "get/set/reset" would be a much better model - but since I am following LIS' lead, and LIS has picked a particular approach to tweak CRUD, I am not inclined to produce a slightly-different-tweak of CRUD that you and I would agree is more elegant and better represents reality.

I am so comforted when I can say over and over "take a look at the LIS spec for that detail" :)

4. Response format

===============

Can we use HTTP status codes rather than the IMS Statusinfo?  I shouldn't really need to parse the message content if its a 2xx and I don't do updates or deletes. (We only created StatusInfo in IMS for use with SOAP, especially cases where there are multiple batched operations in a single request.)

This is an attempt to stay "binding like" and keep it is thin and direct as possible to reduce debate.  I agree that this is something to be debated and discussed a bit more - particularly as IMS moves toward non-SOAP message approaches.

My position in that debate - subject to seeing something better - is that I would rather error information + detail be in the message than in the error codes because it means it is more easily implementable in lots of languages.

If you did not like parsing XML to find the error message, I would almost prefer both an XML and JSON binding of the responses rather than sliding critical information into the response header.

This of course is a "many-pint" debate to get to resolution. :)

I think including detailed error information in the response is a good thing (e.g for logging), but its useful to have the HTTP status codes returned as these tend to be handled by the code libraries used to make the request anyway.

So a compromise position would be to keep the IMS status info XML, return it in the response body, but have the response header contain a useful HTTP status code and not just 200 for everything. It may be IMS, but its still the web!

I am almost ready to agree to this one - but I have one more salvo before I concur.

I would like to be 150% or 200% sure that these error codes will absolutely not confuse, Javascript, Dojo, JQuery, Perl, Cobol, etc etc etc into doing me a favor and eating my return data and blowing up with a traceback in the framework.  And I would want to be assured that old/obsolete versions of these things don't auto-eat returned results based on properly set error codes.

I know that it is REST-heresey to question this - but if the header error code information is redundant and causes the data to be undeliverable in even a small fraction of environments - then I am against it.

Also will proxies eat them?  Will 5-year old proxy software mistakenly eat them?  Will IE6 Javascript eat them?  How about IE5?

One thing we can be sure of (even in IE5) is that if we send a 200 - all the software frameworks/libraries on the planet will deliver the message to the destination application reliably.

And I am also not interested in the standard RESTafarian response of, "If all software, browsers, and operating systems  were re-written in Ruby on Rails the world would be a better place"...  :)

/Chuck

[Scott Wilson]

On 23 Sep 2010, at 17:20, csev wrote:

4. Response format

===============

Can we use HTTP status codes rather than the IMS Statusinfo?  I shouldn't really need to parse the message content if its a 2xx and I don't do updates or deletes. (We only created StatusInfo in IMS for use with SOAP, especially cases where there are multiple batched operations in a single request.)

This is an attempt to stay "binding like" and keep it is thin and direct as possible to reduce debate.  I agree that this is something to be debated and discussed a bit more - particularly as IMS moves toward non-SOAP message approaches.

My position in that debate - subject to seeing something better - is that I would rather error information + detail be in the message than in the error codes because it means it is more easily implementable in lots of languages.

If you did not like parsing XML to find the error message, I would almost prefer both an XML and JSON binding of the responses rather than sliding critical information into the response header.

This of course is a "many-pint" debate to get to resolution. :)

I think including detailed error information in the response is a good thing (e.g for logging), but its useful to have the HTTP status codes returned as these tend to be handled by the code libraries used to make the request anyway.

So a compromise position would be to keep the IMS status info XML, return it in the response body, but have the response header contain a useful HTTP status code and not just 200 for everything. It may be IMS, but its still the web!

I am almost ready to agree to this one - but I have one more salvo before I concur.

I would like to be 150% or 200% sure that these error codes will absolutely not confuse,

Javascript,

its cool:

http://www.w3.org/TR/XMLHttpRequest/

Dojo,

all good:

http://docs.dojocampus.org/dojo/xhrGet#handling-status-codes

JQuery,

no worries:

http://stackoverflow.com/questions/377644/jquery-ajax-error-handling-show-custom-exception-messages

Perl,

can do:

http://search.cpan.org/~gaas/libwww-perl-5.837/lib/HTTP/Response.pm

Cobol,

Seems OK on an IBM CICS mainframe running a Cobol WEB_RECEIVE:

http://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.internet.doc/topics/dfhtl_outmaking_respreceive.html

etc etc etc into doing me a favor and eating my return data and blowing up with a traceback in the framework.  And I would want to be assured that old/obsolete versions of these things don't auto-eat returned results based on properly set error codes.

I know that it is REST-heresey to question this - but if the header error code information is redundant and causes the data to be undeliverable in even a small fraction of environments - then I am against it.

Also will proxies eat them?  

They can eat anything, including the whole response if that's what you want to make them do. You could also make a proxy server that replaced all the IMS StatusInfo XML response bodies with "blarp blarp blarp" if you wanted. However a proxy shouldn't behave in this manner by accident if it claims to implement HTTP.

Will 5-year old proxy software mistakenly eat them?  

HTTP 1.1 has been around 11 years, so they would have had 6 years to figure out how to pass HTTP headers correctly.

Will IE6 Javascript eat them?  

No. 

http://msdn.microsoft.com/en-us/library/ms534650(v=VS.85).aspx

How about IE5?

There was a bug in IE5 to do with 204 status codes ("No content"), so to avoid potential issues you shouldn't use a 204 response.

There was a bug in Mozilla to do with 305 redirects in 2003, but it was fixed.

One thing we can be sure of (even in IE5) is that if we send a 200 - all the software frameworks/libraries on the planet will deliver the message to the destination application reliably.

Also checked Scala, ASP.Net, Django... no worries there either.

Though maybe this one might have some issues: http://secretgeek.net/dod_intro.asp

[csev]

Outstanding!

/Chuck

[Zaitchik, Alan]

Some basic questions about the spec on the Outcomes Extension as regards the Read message type:

1.       Maybe just a nit, but the way section 4.2 is written it implies that the parameter result_resultscore_textstring is “required” in all messages to the ext_ims_lis_basic_outcome_url -- even a Read request. Actually this parameter would make sense in the response back from the TC Outcomes service to the TP, or of course in the TP’s request for an Update (or maybe Delete??) message. Also, the various other parameters listed right afterwards (language, status, date, etc.) are said to be optional but in fact really make no sense in the Read request. So some rewording is probably needed. A material question concerns the Delete message and whether it is required there.

2.       I am confused why result_datasource is optional from the point of view of the TC on a Read. If the TP bothers to include it in the Read request, presumably it needs this identifier or at any rate prefers to have it sent back so it can (efficiently) process the outcome returned by the TC—and all the TC has to do is simply send it back in the response, as illustrated in 4.3. So for what it’s worth I would think that it should be required of the TC to send it back *if* the TP sent it along in the Read request in the first place. It serves the same kind of function for the TP that lis_result_sourcedid serves for the TC on an update or delete.

3.       I guess I am not sure what section 4.3 means by “The values in the result area correspond directly to the values in the POST message.” No personsourcedid form field is discussed elsewhere in this document. I am assuming that the TC response to the Read request it to POST back form fields with the various values as listed in 4.2 and also send back the XML depicted in 4.3. Not sure how personsourcedid fits in here. In fact the TC will typically be able to retrieve the personsourcedid value for the user by simply following the lis_result_sourcedid value into the gradebook, but it might not be possible for some implementations, so it is worth rethinking this.

[Zaitchik, Alan]

Am I correct in thinking that If the response wants to indicate that the message type of the Request was invalid, it cannot do so since it must always return the message type it received when it sends back the response, and in this case that message type was invalid.  The TP will experience a timeout in that the TC will simply not respond. On the other hand the TC can respond to other situations like OAuth failures (bad signature, timeout, missing OAuth parameters in request, etc.)

Perhaps this is exactly as it should be, but I wanted to make sure the point was noticed.

Alan

 

 

[csev]

On Feb 7, 2011, at 12:30 PM, Zaitchik, Alan wrote:

Some basic questions about the spec on the Outcomes Extension as regards the Read message type:

1.       Maybe just a nit, but the way section 4.2 is written it implies that the parameter result_resultscore_textstring is “required” in all messages to the ext_ims_lis_basic_outcome_url -- even a Read request. Actually this parameter would make sense in the response back from the TC Outcomes service to the TP, or of course in the TP’s request for an Update (or maybe Delete??) message. Also, the various other parameters listed right afterwards (language, status, date, etc.) are said to be optional but in fact really make no sense in the Read request. So some rewording is probably needed. A material question concerns the Delete message and whether it is required there.

I changed it to be required only in a update.

2.       I am confused why result_datasource is optional from the point of view of the TC on a Read. If the TP bothers to include it in the Read request, presumably it needs this identifier or at any rate prefers to have it sent back so it can (efficiently) process the outcome returned by the TC—and all the TC has to do is simply send it back in the response, as illustrated in 4.3. So for what it’s worth I would think that it should be required of the TC to send it back *if* the TP sent it along in the Read request in the first place. It serves the same kind of function for the TP that lis_result_sourcedid serves for the TC on an update or delete.

So far this is not used - it might be better to delete it.   The real place this should be modeled is as part of result_datasource.  Let me know what you think.

3.       I guess I am not sure what section 4.3 means by “The values in the result area correspond directly to the values in the POST message.” No personsourcedid form field is discussed elsewhere in this document. I am assuming that the TC response to the Read request it to POST back form fields with the various values as listed in 4.2 and also send back the XML depicted in 4.3. Not sure how personsourcedid fits in here. In fact the TC will typically be able to retrieve the personsourcedid value for the user by simply following the lis_result_sourcedid value into the gradebook, but it might not be possible for some implementations, so it is worth rethinking this.

I deleted the tag for personsourcedid from the example.

/Chuck

[csev]

I don't think that we have gotten to that level of detail.   The implementations I wrote upon receipt of a properly signed request with a bad message type would would have returned an XML blob including the *wrong* message type and an error indication.

/Chuck

[Zaitchik, Alan]

2 more cents...

About result_datasource...
FWIW I think that if TP sends result_datasource in its request to TC then TC should include it in the response back, and if not then (of course) not. I can imagine cases where the TP will want back the Tool-internal identifier, to help it (easily) find the Tool location or thread that generated this outcome (Update) or the location or thread that asked for it (Read).

About section 4.3...
Actually I meant to ask what it means when you say "The values in the result area correspond directly to the values in the POST message." I don't see how they are. Maybe it's a question of which POST is meant. They wouldn't be in the Read message POST from TP to TC.