There is a great discussion going on between Brian Whitmer (Canvas Instructure) and David Lippman (iMathAs) in a Canvas forum about custom parameters and resource links.

http://groups.google.com/group/canvas-lms-users/browse_thread/thread/bd2932b9a6a8bb6e

My Response

Brian,

While the spec is not explicit in this area, the simple fact that each LTI placement in a CC 1.1 cartridge has its own custom parameters and you can have many links in a cartridge naturally implies that each link can have its own distinct custom parameters. In the LTI 1.0 specification, the notion of how custom parameters work was left vague when it comes to authoring links (i.e not as part of an import).

When folks read the LTI 1.0 spec some implementations made it so that (a) the single tool shared configuration was the only place that custom parameters be set and other implementations made it so (b) that custom parameters could only be set on the individual resource link. The more common approach was (a) which sounds like the approach you took in Canvas.

This worked well until you think of the export/import cartridge use case where tools like an assessment engine want to store a setting like “which assessment” in a custom field. Pearson, McGraw-Hill and lots of folks want to do this where they want many resource links in a cartridge and have those links point to different resources *without* adding a parameter to the URL (which is not recommended) – which would mess up much more than adding a custom parameter. Of course some of my presentations (i.e. using resource_link_id configuration) talk about the way a tool can work around the lack of per-resouce custom parameters parameter support in an LMS. This work-around is sufficient for initial link authoring in an LMS where the course is being built – but fails across export/import as resource_link_ids are not carried in the CC.

So this meant that LMS’s could not be used to author proper cartridges unless they allowed per-link custom parameters so these could persist across an export / import path. Yikes! We figured that many who wanted to make cartridges would simply use an LMS to do it while waiting for a specific authoring tool or process.

So in LTI 1.1, we made it more explicit in section B.7 with the following new text:

B.7.1 Instructor Creates New Tools
In the case that the TC decides to allow the instructor to place tools without administrator action by getting a URL, key, and secret from a TP and plugging them into a course structure, it is a good practice to allow the instructor to enter custom parameters without requiring administrator assistance. Some TPs will need custom parameters to function properly. Also if the instructor is using a TC to produce an IMS Common Cartridge with LTI links in the cartridge, often setting custom parameters for a tool placement is an essential part of authoring a cartridge.

B.7.2 Admin Creates New Tools, Instructor Only Places Tools
Another common case is to only allow the administrator to create new tools (i.e., key/secret/url) and then let the instructor place those pre-configured tools in their courses. In this use case, instructors never handle url/key/secret values. Even in this use case it is important to allow the instructor to be able to set or augment custom parameters for each placement. These parameters may be necessary for the TP to function and/or may be necessary if the instructor is building a course in the TC to be exported into an IMS Common Cartridge. It is not necessary to always give the instructor the option to configure custom parameters, but it should be possible for the administrator to make a choice to reveal a user interface to set custom parameters.

You can also read B.7.2 as to applying to a situation where an instructor makes their own tool configuration to share across multiple resource links. The best practice is to have both the shared config and the resource-link contribute to the custom parameters.

You merge the custom parameters at launch if they exist both places – I think that my code for this treats the shared / admin as having higher precedence. You would naturally take the same merge approach when exporting to a CC 1.1 – since the CC 1.1 has no concept of a shared link – it only knows about the resource link – you have to pull in the inherited parameters on export or data will be lost.

Now lets talk about LTI 2.0 that does not exist yet and how it treats this in the draft versions so far. LTI 2.0’s view of a cartridge explicitly models two separate items. The first is a tool configuration with url, vendor, etc. The tool configuration registers itself mime-type style resource-handler as a “pearson-mymathlab-quiz” indicating that once this tool is installed it handles resources that are of tyoe “pearson-mymathlab-quiz. The second is a resource-link that is the actual link in the course structure that includes title, custom parameters, and needs a resource handler of type “pearson-mymathlab-quiz”.

If you look at the LTI 1.0 / CC 1.1 data model, for simplification, we condensed these into a single structure. Simplification makes things easier sometimes and harder other times.

LTI 2.0 will add two new resource types to a future CC version, keeping the basiclti all-in-one resource type. But my guess is that once the LTI 2.0 CC support makes it into the field, folks will quickly switch as it is *much* prettier. One of the major advantages of the LTI 2.0 approach (at the cost of more UI and workflow complexity) is that since the resource handler idea is a bit of an abstraction between resource links and tool configurations, it allows LMS builders and LMS admins to re-map those resource handlers to solve use cases like living behind a firewall or having a local copy of Pearson MyMathLab in South Africa.

The 2.0 specs are pretty mature but it always takes a while for adoption so we need to focus on and deal with the current CC and LTI 1.1 and get it right so it works well while we finish up LTI 2.0 and its associated CC release and get it out and into the marketplace.

Hope this helps.