...
LTI resources served from the edX platform are (e.g. problems, units, subsections, chapters) are meant to be consumed as small components hosted by an external LMS (the LTI Consumer). The According to the basic relationship set up by the LTI Specification, it is the responsibility of the external host LMS (the LTI Consumer) to determine the relationship between these individual resources and a course should be fully managed by any concept of a course. Edx as an LTI Provider cannot make any statements about collections of LTI resources as a course in the external LMS. In the future, there is no guarantee The fact that these resources will have any relationship to a course inside the edX platform.Based LTI resources, according to the current implementation in edX, are also created in the context of an edX course is not called for as part of the LTI Specification. According to the original edX as LTI Provider architecture document, this decision was made in part because it "...greatly simplifies the user management and [resource] permissioning model...".
As stated in this same architecture document, based on the current implementation of edX as an LTI Provider, it is still currently recommended to use a separate edX course for these LTI resources. This It is also recommended that the course should never be used by non-LTI users. However, any community request that ties LTI resources more permanently to an edX course is in conflict with the future direction of the platform, where we would rather like to decouple these. This includes, but is not limited to, any changes that would require the LTI users to actually enroll in the edX course being used to provide the LTI resources.It is
However, based on the above discussion of the roles of LTI Consumer and LTI Provider in relationship to a course, the future architectural direction of LTI resources inside edX should allow for the loosening of this dependency. Any requests or decisions that couple LTI resources served through edX as an LTI Provider even more tightly to an edX course leaves less flexibility around this functionality by making assumptions about the grouping of this content that may not be true in the future.
One such request was to enroll LTI users in the edX course used in the current LTI Provider implementation. This would more greatly couple our LTI Provider implementation to edX courses. The original architecture document details that this enrollment of LTI users was avoided. However, this document also leaves unanswered question about the future intention of this coupling. For example, it explains how analytics data is coupled with the edX course, but not why, nor how and if that coupling can equally be loosened.
It is also understood that the single float outcome that is returned by LTI 1.1 may not be sufficient, and a consumer an LTI Consumer may require more data from the edX platform in the future. If other administrative data is required, we will need to discuss APIs that can extend the current implementation through some standard specification, whether that be something from LTI 2.0, or an XBlock-like extension, or some similar standard. This has not been designed in detail, but is acknowledged here to give an indication of the ways in which the LTI Provider implementation might be extended if necessary.