Sharebar?

resource_link_id. in ContentItemSelectionRequest

resource_link_id. in ContentItemSelectionRequest

Hello,

I'm trying to understand if resource_link_ids must/can/must not be present in ContentItemSelectionRequest requests (deep linking 1.0). Spec says "should not", the implementation guide says "should"

These seem contradictory:
From deep linking 1.0 spec (https://www.imsglobal.org/specs/lticiv1p0/specification)

The TC should also pass the other parameters about the tool consumer, the user, the context and the user's roles as would be included in a launch request (see [LTI, 11, Basic Launch Data]). The following parameters should not be passed:
resource_link_id
resource_link_title
resource_link_description
launch_presentation_return_url
lis_result_sourcedid

and this from implementation guide (https://www.imsglobal.org/learning-tools-interoperability-implementing-d...):

Step 1: Is this an LTI ContentItemSelectionRequest message?
The required characteristics of an LTI ContentItemSelectionRequest message are as follows:
It should be an HTTP POST message
It should include a POST parameter named lti_message_type with a value of ContentItemSelectionRequest
It should include a POST parameter named lti_version with a value of LTI-1p0 ( or LTI-2p0 for an LTI 2 connection)
It should include a POST parameter named oauth_consumer_key with a non-empty value
It should include a POST parameter named resource_link_id with a non-empty value

Can anyone clarify?

Deep Linking 1.0 is deprecated

To start, that version of the spec is deprecated and only implemented by a couple platforms. The new version of the spec (Deep Linking 2.0) that works with LTI 1.3 is clearer on many points like this. I wouldn't recommend implementing Deep Linking 1.0 unless you already know it's for a limited and deprecated situation.

 

But within this spec, I'm not surprised there is some unintentional contradictions. LTI 1.1 requires a resource_link_id for all LTI launches, and the first deep linking spec, built on LTI 1.1, may have at some point required that as well because of the base requirement.

Doing a Deep Linking launch is meant to discover resources, but not be a resource itself, thus it doesn't really make sense for it to have a resource_link_id. So, I don't know what the actual final correct version is for DL 1.0, but by best practice the resource_link_id property probably shouldn't be included for ContentItemSelectionRequest launch and I'd expect tools to not use it for anything if it's present.

thank you, this helpful.

thank you, this helpful.

Re: Deep Linking 1.0 is deprecated

that version of the spec is deprecated and only implemented by a couple platforms

I would disagree with this statement and believe that the content-item/deep linking 1.0 message spec has been implemented by more than just a "couple" of platforms. Indeed I am not aware of a platform used within HE, for example, which does not support it.

But my answer to the question posed (without checking the wording of the specs for inconsistencies as not all the documents are available to non-IMS members), is that it is not possible for a content-item/deep linking request message to include resource link related parameters because, at the time the message is sent, the resource link does not exist. A platform uses the response message to create the resource links from which launch messages can then emanate. The essence of this message type is that it allows a tool to be involved in the creation of resource links within a platform.

makes sense. thanks

makes sense. thanks