I am the lead developer for IMathAS (www.imathas.com), which is a
BasicLTI v1.1 compliant tool (provider), and a CC v1.1 compliant write
tool.
Basically, a course on my system includes a bunch of non-QTI
assessments, which I want to be able to bulk-load into Canvas as BLTI
placements using CC v1.1.
All of my BLTI items in the cartridge use the same launch URL, and use
a custom property to specify the assessment on my platform the
placement should load.
When I try importing this into Canvas, Canvas creates a separate
external tool for each of these placements, even if I have previously
set up an external tool with a "Match By: URL" option.
I think you're going to run into problems if all of the tools have the same URL but different custom fields. In Canvas, custom fields are stored on the tool configuration, not the link configuration, so yes, it makes sense that Canvas is creating multiple tools since each of your links has different custom fields.
The problem you're going to hit is if all your URLs are identical, then since LTI matches by URL, the system doesn't know which tool configuration to pick for each link, and all links will get sent with the same custom fields.
If I insert two links, one for Quiz 1 and one for Quiz 2, there's going to be a problem. LTI specifies that tool retrieval should happen at tool launch time, so when you click either link, Canvas is going to search for the first tool it can find that matches the URL specified ( http://example.com). So both links will use Tool 1 configuration, and both links will launch Quiz 1.
This is a problem with the LTI specification, and I don't believe will be unique to Canvas. Correct me if I'm wrong.
As far as properly crafting your CC package, it might be easiest to build up a course in Canvas that's configured how you like, exporting that to CC, and seeing what it looks like. If there are discrepancies between what you see and what you think you should see please let us know.
On Tue, Jan 10, 2012 at 8:01 PM, David Lippman <drlipp...@gmail.com> wrote: > Hi,
> I am the lead developer for IMathAS (www.imathas.com), which is a > BasicLTI v1.1 compliant tool (provider), and a CC v1.1 compliant write > tool.
> Basically, a course on my system includes a bunch of non-QTI > assessments, which I want to be able to bulk-load into Canvas as BLTI > placements using CC v1.1.
> All of my BLTI items in the cartridge use the same launch URL, and use > a custom property to specify the assessment on my platform the > placement should load.
> When I try importing this into Canvas, Canvas creates a separate > external tool for each of these placements, even if I have previously > set up an external tool with a "Match By: URL" option.
> Am I doing some wrong, or is there some way I can adjust my output to > work better with Canvas? If it would help, you can download a copy of > an example CC export at > http://www.myopenmath.com/course/files/CCEXPORT44.imscc
Interesting. I had interpreted the specs as implying that the custom
fields should be link-level, not tool-level.
The Use Case for CC placements says "When a TC User launches an LTI
link imported from the Common Cartridge, the TC signs the launch
request using the pre-configured credentials associated with the TP
address."
However, the custom fields are specified for each individual link,
which implies they are not part of the domain credentials.
Additionally, the specs given an example of "For example if the link
were a section in an eTextbook, there might be a setting like:
<parameter key="section">1.2.7</parameter>" which suggests to me that
the custom fields were intended to be for link-specific purposes.
Perhaps not. Sadly, the specs are not that specific :)
Thanks for the suggestions. I'll play around with Domain matching
tomorrow and see if I can get something to work better that way.
-David
On Jan 12, 9:12 am, Brian Whitmer <br...@instructure.com> wrote:
> I think you're going to run into problems if all of the tools have the same
> URL but different custom fields. In Canvas, custom fields are stored on the
> tool configuration, not the link configuration, so yes, it makes sense that
> Canvas is creating multiple tools since each of your links has different
> custom fields.
> The problem you're going to hit is if all your URLs are identical, then
> since LTI matches by URL, the system doesn't know which tool configuration
> to pick for each link, and all links will get sent with the same custom
> fields.
> If I insert two links, one for Quiz 1 and one for Quiz 2, there's going to
> be a problem. LTI specifies that tool retrieval should happen at tool
> launch time, so when you click either link, Canvas is going to search for
> the first tool it can find that matches the URL specified (http://example.com). So both links will use Tool 1 configuration, and both
> links will launch Quiz 1.
> This is a problem with the LTI specification, and I don't believe will be
> unique to Canvas. Correct me if I'm wrong.
> As far as properly crafting your CC package, it might be easiest to build
> up a course in Canvas that's configured how you like, exporting that to CC,
> and seeing what it looks like. If there are discrepancies between what you
> see and what you think you should see please let us know.
> Thanks,
> -Brian
> On Tue, Jan 10, 2012 at 8:01 PM, David Lippman <drlipp...@gmail.com> wrote:
> > Hi,
> > I am the lead developer for IMathAS (www.imathas.com), which is a
> > BasicLTI v1.1 compliant tool (provider), and a CC v1.1 compliant write
> > tool.
> > Basically, a course on my system includes a bunch of non-QTI
> > assessments, which I want to be able to bulk-load into Canvas as BLTI
> > placements using CC v1.1.
> > All of my BLTI items in the cartridge use the same launch URL, and use
> > a custom property to specify the assessment on my platform the
> > placement should load.
> > When I try importing this into Canvas, Canvas creates a separate
> > external tool for each of these placements, even if I have previously
> > set up an external tool with a "Match By: URL" option.
> > Am I doing some wrong, or is there some way I can adjust my output to
> > work better with Canvas? If it would help, you can download a copy of
> > an example CC export at
> >http://www.myopenmath.com/course/files/CCEXPORT44.imscc
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).
Folks reading 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 marke 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.
Also, Brian, I tried your idea and set up an External Tool in Canvas
with Match By: Domain, and then importing in a modified cartridge that
removed the custom fields and used query-strings instead. Canvas did
not match them, and instead imported each LTI item in the CC as a
separate external tool as it did before.
David
On Jan 13, 5:29 am, "Dr. Chuck" <drch...@gmail.com> wrote:
> 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).
> Folks reading 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 marke 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.
David, sorry I wasn't clear. Adding a domain-matching tool wouldn't have any effect on the CC import process. I'm less familiar with our CC import process than I am with our LTI code, but I do know that tools and tool links are in separate models, that is probably reflected in the CC format somehow. I'd probably suggest building what you want by hand inside of a Canvas course, exporting the course as CC, and seeing what the difference is between that package and the one you're trying to import.
Chuck, since you chimed in :-).
I talked to Bracken and he finally convinced me that custom parameters on links *and* tools is an ok thing. I don't mean to be slow, it just takes me a while sometimes. My worry is the usability side of things. The reason I tend to push people to use query parameters on a URL is that at least in that case the user only has to copy and paste on "weird" value instead of two (a URL and custom parameters) when inserting a link.
My ideal preference would be that the instructor wouldn't have to do any copy and pasting at all. That's what I'm shooting for with the "Link Selection" extension you can see in our API docs https://canvas.instructure.com/doc/api/link_selection_tools.html. The admin sets up the tool, the teacher gets a nice dialog where they pick their resource, and the values are automatically inserted. We can add custom parameters to that sort of workflow without causing the link creator any additional burden.
Also the mime-type idea is interesting. Have you looked at all at Google's Web Intents project? This is the first I've heard of LTI 2.0..
On Fri, Jan 13, 2012 at 11:05 AM, David Lippman <drlipp...@gmail.com> wrote: > Thanks for the clarification, Chuck.
> Also, Brian, I tried your idea and set up an External Tool in Canvas > with Match By: Domain, and then importing in a modified cartridge that > removed the custom fields and used query-strings instead. Canvas did > not match them, and instead imported each LTI item in the CC as a > separate external tool as it did before.
> David
> On Jan 13, 5:29 am, "Dr. Chuck" <drch...@gmail.com> wrote: > > 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).
> > Folks reading 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 marke 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.
My tool is designed so that if a placement is made without custom
parameters, my tool will guide the instructor through selecting what
assessment should be associated with that placement (what Chuck called
resource_link_id configuration). This works great for an instructor
trying to set up their own content links.
Unfortunately, while I can use the same Tool in Canvas several times
to create multiple placements linked to different assessments, those
connections are based on the resource_link_id which, as Chuck
mentioned, is not included in a CC export, so all those links between
placements in Canvas and assessments on my system will not persist
across export/import.
Just the same, I tried making two placements in Canvas with the same
tool and exporting it. Only one LTI xml file was created, and neither
item in the organization section referenced it, which was odd. In the
module view, only one of the placements made with the tool showed up
after import, so one of them completely got lost in the export/import
process. As I suspected, the link between the placement and an
assessment on my system was lost in the process as well.
Your link selection extension seems like an interesting idea for
building courses that can be exported, though as discussed it might
make more sense to be setting a custom parameter rather than a
different URL.
David
On Jan 13, 12:28 pm, Brian Whitmer <br...@instructure.com> wrote:
> David, sorry I wasn't clear. Adding a domain-matching tool wouldn't have
> any effect on the CC import process. I'm less familiar with our CC import
> process than I am with our LTI code, but I do know that tools and tool
> links are in separate models, that is probably reflected in the CC format
> somehow. I'd probably suggest building what you want by hand inside of a
> Canvas course, exporting the course as CC, and seeing what the difference
> is between that package and the one you're trying to import.
> Chuck, since you chimed in :-).
> I talked to Bracken and he finally convinced me that custom parameters on
> links *and* tools is an ok thing. I don't mean to be slow, it just takes me
> a while sometimes. My worry is the usability side of things. The reason I
> tend to push people to use query parameters on a URL is that at least in
> that case the user only has to copy and paste on "weird" value instead of
> two (a URL and custom parameters) when inserting a link.
> My ideal preference would be that the instructor wouldn't have to do any
> copy and pasting at all. That's what I'm shooting for with the "Link
> Selection" extension you can see in our API docshttps://canvas.instructure.com/doc/api/link_selection_tools.html. The admin
> sets up the tool, the teacher gets a nice dialog where they pick their
> resource, and the values are automatically inserted. We can add custom
> parameters to that sort of workflow without causing the link creator any
> additional burden.
> Also the mime-type idea is interesting. Have you looked at all at Google's
> Web Intents project? This is the first I've heard of LTI 2.0..
> -Brian
> On Fri, Jan 13, 2012 at 11:05 AM, David Lippman <drlipp...@gmail.com> wrote:
> > Thanks for the clarification, Chuck.
> > Also, Brian, I tried your idea and set up an External Tool in Canvas
> > with Match By: Domain, and then importing in a modified cartridge that
> > removed the custom fields and used query-strings instead. Canvas did
> > not match them, and instead imported each LTI item in the CC as a
> > separate external tool as it did before.
> > David
> > On Jan 13, 5:29 am, "Dr. Chuck" <drch...@gmail.com> wrote:
> > > 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).
> > > Folks reading 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 marke 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 fact that there was only one lti xml doesn't surprise me, since you only had one tool configured. The connection between links and tools is very loose, so it also makes sense that the items wouldn't reference the specific tool. I'm not sure why there was only one item added instead of two, though. Can you send a copy of the export package?
I agree custom parameters would be a nice thing to add to the link selection extension. We'll have to change our model a bit because, like I said before, we're not currently built to have custom parameters tied to the link placement, only to the tool itself. But that makes sense to add.
On Fri, Jan 13, 2012 at 8:03 PM, David Lippman <drlipp...@gmail.com> wrote: > Brian,
> My tool is designed so that if a placement is made without custom > parameters, my tool will guide the instructor through selecting what > assessment should be associated with that placement (what Chuck called > resource_link_id configuration). This works great for an instructor > trying to set up their own content links.
> Unfortunately, while I can use the same Tool in Canvas several times > to create multiple placements linked to different assessments, those > connections are based on the resource_link_id which, as Chuck > mentioned, is not included in a CC export, so all those links between > placements in Canvas and assessments on my system will not persist > across export/import.
> Just the same, I tried making two placements in Canvas with the same > tool and exporting it. Only one LTI xml file was created, and neither > item in the organization section referenced it, which was odd. In the > module view, only one of the placements made with the tool showed up > after import, so one of them completely got lost in the export/import > process. As I suspected, the link between the placement and an > assessment on my system was lost in the process as well.
> Your link selection extension seems like an interesting idea for > building courses that can be exported, though as discussed it might > make more sense to be setting a custom parameter rather than a > different URL.
> David
> On Jan 13, 12:28 pm, Brian Whitmer <br...@instructure.com> wrote: > > David, sorry I wasn't clear. Adding a domain-matching tool wouldn't have > > any effect on the CC import process. I'm less familiar with our CC import > > process than I am with our LTI code, but I do know that tools and tool > > links are in separate models, that is probably reflected in the CC format > > somehow. I'd probably suggest building what you want by hand inside of a > > Canvas course, exporting the course as CC, and seeing what the difference > > is between that package and the one you're trying to import.
> > Chuck, since you chimed in :-).
> > I talked to Bracken and he finally convinced me that custom parameters on > > links *and* tools is an ok thing. I don't mean to be slow, it just takes > me > > a while sometimes. My worry is the usability side of things. The reason I > > tend to push people to use query parameters on a URL is that at least in > > that case the user only has to copy and paste on "weird" value instead of > > two (a URL and custom parameters) when inserting a link.
> > My ideal preference would be that the instructor wouldn't have to do any > > copy and pasting at all. That's what I'm shooting for with the "Link > > Selection" extension you can see in our API docshttps:// > canvas.instructure.com/doc/api/link_selection_tools.html. The admin > > sets up the tool, the teacher gets a nice dialog where they pick their > > resource, and the values are automatically inserted. We can add custom > > parameters to that sort of workflow without causing the link creator any > > additional burden.
> > Also the mime-type idea is interesting. Have you looked at all at > Google's > > Web Intents project? This is the first I've heard of LTI 2.0..
> > -Brian
> > On Fri, Jan 13, 2012 at 11:05 AM, David Lippman <drlipp...@gmail.com> > wrote: > > > Thanks for the clarification, Chuck.
> > > Also, Brian, I tried your idea and set up an External Tool in Canvas > > > with Match By: Domain, and then importing in a modified cartridge that > > > removed the custom fields and used query-strings instead. Canvas did > > > not match them, and instead imported each LTI item in the CC as a > > > separate external tool as it did before.
> > > David
> > > On Jan 13, 5:29 am, "Dr. Chuck" <drch...@gmail.com> wrote: > > > > 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).
> > > > Folks reading 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".
