Developer workshop - CCv1.1 and basic LTI v1.0
Summary of the IMS developers' workshop.
Developer workshop - CCv1.1 and basic LTI v1.0
Kevin Riley
Common Cartridge solves a problem that really should have been solved years ago. The real purpose of Common Cartridge is to crack the goal of routinely exchanging content across systems. We took the stance of working with industry - in particular the LMSs and the publishers - to determine which features customers actually wanted installed. The other thing was that it was important that Common Cartridge be easy to implement, not just for platform vendors, but also easy to import content.
The educational paradigm that CC supports is essentially self-directed learning with the assumption that there is an instructor in the loop. We assume they have access to a platform where they can work at their own speed, and a peer group with whome they are working. Finally, we based it on existing standards that have already been widely adopted and were in themselves very stable.
CC version 1.0 included cartdridge metadata - the description of the cartridge itself - and resource metadata - metadata associated with a resource in the package. We basically provided a means by which we could identify who the resource should be visible to, instructor or students. The default was that it would be visible to all. We had intended to use the 'invisible' element from Content Packaging, but this was already in use in different ways by the community, so we couldn't guarantee the results. So we used the resource metadata itself.
There is a whole range of content that can be placed in a cartridge: html, web links, media files, application files, etc. We also wanted to be able to include assessments in a cartridge. We went through an exercise with the publishers, asking them to review what question types they actually used. It became clear there were six basic types: multiple choice (single or multiple response), true/false, essay, fill-in-the-blank, and pattern match. Also, we introduced a discussion forum, and created a schema to introduce the discussion forum and integrate a group of users. And finally, content authorization to protect content - not DRM, but just a way for publishers to check that the licensing is being respected.
In CCv1.1 some changes were introduced. In roles metadata, we created the role of 'mentor' for parent. There is also use of a third role in other areas - the mentor could be an employer, for example. In higher ed, the mentor role might not be used - in any case where the mentor does not exist, content available for the mentor will be made available to the instructor.
Another area related to content in different languages, not only to present in different languages, but also, the content might be in different languages, as in a language-teaching resource. You define a prime language and secondary languages to be refrenced. Also, there was a request to include instructions for users to complete assessments. There is a rubric from QTI we use. Additionally, there is a rubric for the inclusion of curriculum standards (workshop on this tomorrow) across different regions of the world and different authorities. Also, there is the in clusion of the 'lesson plan' in the cartridge.
And finally, most importantly, there is the integration of LTI, which is the subject of today's seminars.
The actual spec defines unambiguous rules for building cartridges, describes additional constraints through the use of schemas, and offers two levels of testingcompliance for cartridges and for platforms. Common Cartridge does not define the runtime - there is an implied runtime, but we have stepped away from explicitly defining the internal operations of the platform. This allows vendors to more easily adapt to the spec.
The LTI incorporates the possibility of linking to services that may be run at the publisher's site. We can define this as just another resource in the cartridge. The same protocol can also be used for accessing eBooks and other kinds of services.
Core Cartridge metadata is defined in Dublin Core and mapped to IEEE LOM. Metadata resides in the imsmanifest file. It is not order-sensitive. Also, any requirement for a specific player by cartridge content must be declared in the Cartridge metadata.
At the level of resource metdata: roles metadata is associated with the resource, and restricts who the resource is assessible to, and restructs access. Curriculum metadata identifies learning objectives, addressed by a resource (samples of roles, curriculum metadata shown).
Conceptually, there are four kinds of content in a CC: "learner experience data", which is your traditional lesson content; "supplemental resources", which is additional material (including extra questions) an instructor can access during delivery; "operational data" explaining how the content behaves in the platform at runtime; and "descriptive metadata" which is the cartridge metadata describing the whole thing.
Compared to content packaging (CP) version 1.2 (CPv1.2) we decided to omit multiple organizations of content. We also removed the CP cartridge version characteristic object, so content package tools couldn't open cartridges - they must be opened by something that is cartridge-aware. Also deleted were sub-manifests, as well as inter-package links (ie., xpointer). Packages really need to be stand-alone in their own right.
We added things as well. For example, the root folder for shared content. Associated content in a learning application object directory. There is a schema for authorization data.
- diagram - links between resources and cartridges, allowed and disallowed
Assessments represent instances of QTI. They can embed any of the question types supported by the CCv1.0 profile of QTI. An assessment can contain a number of attributes, including number of attempts, time limits, and whether late submission is allowed. Cartridges offering feedback must support Yes/No and Distractor. The spec also, as mentioned, allows for a qticomment element (from the QTIv1.2 rubric) to allow for instructions on how to complete the assessment. (demo - qticomment element)
Question banks can be included, as an instance of the QTI objectbank. If one is included, only one can be included. You can embed any of the supported question types. While questions are used in assessments, thy cannot be referenced by other resources in the cartridge.
Finally, the Learning Tools Interoperability (LTI) specification allows tools to be launched and data to be returned to the LMS that launched the cartridge. (demo: basic LTIv1.0 description) It is a new resource time, an LTI call, and within that we can hold a description of how to access that service. In addition, eBooks can also be integrated in the same manner. So we can provide a reference to an eBook directly from the LMS, such that the reference points directly to the place in the eBook (section and page) relevant to the placement in the course. The publisher can therefore put a set of tokens into the cartridge that gives the correct reference into the eBook (this could be opaque, but at least one Publisher - Pearson - will make some references available as parsable strings). eBooks will be offered for this as a hosted service. And some publishers are bulding eBooks into applications, as resources accessible from the application.
There are two forms of authorization: one on the import of a cartridge (is this a valid site, does it have a license), and one on use, which is anonymous, and is authorization by PIN number. It is not foolproof; people can bypass it, but if they do, it is clearly done - it is perfectly visible that they intended to do it. Authoization is via an authorization server - for the import, you go to a single source (the assumption is that the cartridge is covered by a single license).
The Common Cartridge Alliance is dedicated to achieving adoption. We have the specification, and will some have version 1.1, as well as a tool for profiling IMS specifications (ScehmaProf) for profiling IMS (and other) specifications. There is a profile registry, so people can submit profiles and share them. We actually have cases where people independent of us have used SchemaProf. There is a compliance program to help people adopt to the spec (the end-user community is tired of hearing excuses about why they can't import content from different people). There is a collaboration program and a CC forum (the Common Cartridge Alliance website is http://www.imsglobal.org/cc/alliance.html but you must be a paid subscriber to access the forum).
There is a compliance program and a mark you can use for recognized compliant resources (you have to be a paid-up member to comply). There is a directory of resources: http://www.imsglobal.org/productdirectory/directory.cfm Also, JISC has created a 'transcoder' that created common cartridges from other types of resource. http://www.jisc.ac.uk/whatwedo/projects/transcoder.aspx
IMS Workshop Notes - Chuck Severance
Homework (to do while you're ignoring the lecture):
1. Join the developers network (free): http://tinyurl.com/imsdn-forum
We talk about code & move code around, but not about the spec itself. It requires a free IMS community account.
2. Make sure you can edit text documents without messing them up. That is, no MS-Word or anything like that imposes formatting. Use BBEdit, TextMate, TextWrangler, etc.
3. Decide whether you're going to use Java or PhP (or both). Unless you are an experienced servlet developer in Java, use PHP.
4. Install PHP - use XAmpp
5. Unzip the PHP from the DVD into the directory and test your install. From
http://code.google.com/p/ims-dev/
Get the latest handout: http://www.dr-chuck/ims
Learning Tools Interoperability
We have htree major types of LTI:
- Simple LTI - not a formal spect - May 2008
- Basic LTI - launch plus outcomes part of IMS common cartridge 1.1
- Full LTI - end of 2009
Basic LTI is a profile of LTI 2.0 - the focus is on launch and LTI integration. As we saw yesterday, the user experience is to click on the link and see the tool. The LTI tool is a proxy tool inside the LMS (so the link is internal to the LMS) which posts a form with learner and a secret and then forwards it to the vendor site, which verifies the secret and sends a cookie with a session and a redirect, which opens the service.
It's very simple to write for; it's simply REST-based. You basically get four kinds of information sent on every request:
- the LTI version number
- resource link ID - the LMSs representation of the resource
- user ID - an opaque string, from the LMS, with no identifying information
- roles - we just take the roles from LIS (Learner Information) - assume that tools key off 'instructor' string, otherwise you're a non-instructor
- a bunch of data pieces from LIS (we used underscores because many systems don't like dashes): lis_person_name_full, lis_person_contact_emailprimary, lis_person_sourced_id, context_id, context_title, tool_consumer_instance_guid (this is the instance of the LMS, your LMS's domain name), tool_consumer_instance_description (this the description of your LMS).
Some of these data elements are optional. For example, an LMS might not decide to send the person's name. The whole LTI is designed to be 'sandboxable'. The absolute minimum ser is LTI version, resource_link_id, and (maybe) context ID.
Basic LTI in Common Cartridge: the basic idea is that, in the Cartridge Use case, the publisher wants to point to something:
- so you need the URL
- then there are custom parameters (not to be messed with by the LMS) - the LMS parameters are under 'extensions'. They can embed context information, version info, etc., whatever they want. The idea is, whatever they put in here, they will get back when the cartridge loads (if they need to ensure it's the same, they can encode it).
- the extensions are generated by the LMS and are namespaced by the LMS. For example, Sakai might send the frame-height, or some other LMS-specific information.
- vendor - some human-readable info about the vendor.
The basic LTI security model is based on OAuth. See http://www.oauth.net It signs messages using time-stamp, nonce. We use trust between pairs of servers. Maybe one day there will be three-legged OAuth in order to support identity servers or third-parties (like Twitter). We're not going to try to communicate to you through some kind of third party identity who the user is.
The tool decides the level of security. It may require all the security values, or none of them. So, for example, it could check time skew (how old the request is) and nonces (there is literally no way to alter them, so there's no man-in-the-middle problem). See http://www.intertwingly.net/blog/1585.htmlOauth depends on reasonably long secret - a 4-charactr pin isn't very secret. You want them long, ugly and nasty. Right now, they are hand-delivered ("passed out-of-band"). There are two levels of secrets: the site-wide password, and the resource-level password: an individual license or one-course license. Note: ou don't have to have either or both.
The LMS admin calls the tool provider, the provider generates a secret, and keys it in over the phone. Inside the LMS there will be some list of providers and passwords (with an editing screen to change them). The resource-level secret is assigned by URL, resource key, and secret. The LMS Secret implies that the user_id and course_id values are the same from launch to launch. But with the resource level secrets, values such as user_id and course_id in launches should be modelled linked to the resource or key.
(Description of OAuth - *way* too fast to follow if you didn't already know the spec - I'll cover this in a later post).
OAuth implementation patters: we create an array or property bag of parameters and pass it to OAuth to sign. Then we send the signed data. The tool receives the post, calls OAuth to pull the data from the request, and asks OAuth to validate it. OAuth calls your 'store' for lookup kys, etc. The pattern is, you put all this into a form, and then you press the submit button (you have to deal with the case where Javascript is turned off, so you have to include the submit button in the basic configuration, or a bit of clever Javascript that will emulate a button-push). You hand the form to OAuth, which processes it, and if it is approved, you do stuff with it. If it is rejected, you return to the launch_presentation_return_url.
Basic LTI depends on IMS Tools Interoperability for support of outcomes. It's a very simple message signature. If my LMS supports outcomes, I include a field that is defined to support outcomes. All I send is the outcome and the tool launch ID. The security is separately established between tool and LMS. The tool vendor has to receive out-of-band authorization to set data (send outcomes) back to the LMS. Very simple, not very complete.
I (Chuck) added an appendix on LTI outcomes recommendations. There may be some discussion on this - conversation in the room on how to report outcomes (eg., grades). Maybe some XML? (Sounds like Wilbert speaking). We're not replicating CMI or SCORM tracking. If people what to get together and exchange data, fine. The work for outcomes in the full LTI is still under development.
The sample code is available at http://code.google.com/p/ims-dev/
org.imsglobalorg.basiclti.BasicCTIUtil.java
blti.util.php
It is wide open, and you can become a committer to this code; I will probably change the Apache committer document and change it to IMS.
Afternoon (Chuck Severance)
Working with the sample Java and PHP implementations.
http://code.google.com/p/ims-dev/
Use my oauth code, not theirs - I have caught flaws in their code.
org.imsglobalorg.basiclti.BasicCTIUtil.java
blti.util.php
There's no LMS-specific code in there, and any LMS can use this code.
There are four basic methods in the code:
- validate - take a look at a descriptor out of a cartridge and validate it
- parse - parsing the descriptor - looks at the XML and extracts the data
- sign - signing method - merge these properties with LMS data, secret, etc. Returns properties with oauth junk in it.
- post - pass the properties to (??)
Some activities are using some code. A building block from Alan bery, U. Amsterdam. Stephen Vickers, eg. http://projects.oscelot.org/gf/project/ ...
Also - JSR portlet for Sakai (maybe available in version 2,7) and planned for Moodle 2.0 (and a backport for 1,9 and 1.8) - developers are working on it. Or Pythn - www.tsugiproject.org - my take on a personal learning environment. It talks a number of sifferent protocols - simple LTI, basic LTI, facebook and Google.
(various other exercises and tests - sorry this is pretty random at the end here, but we went through all the code - I'll analyze and have more on this in the future - I have working versions of all the code and have been through it messing around with it.).
Developer workshop - CCv1.1 and basic LTI v1.0
Kevin Riley
Common Cartridge solves a problem that really should have been solved years ago. The real purpose of Common Cartridge is to crack the goal of routinely exchanging content across systems. We took the stance of working with industry - in particular the LMSs and the publishers - to determine which features customers actually wanted installed. The other thing was that it was important that Common Cartridge be easy to implement, not just for platform vendors, but also easy to import content.
The educational paradigm that CC supports is essentially self-directed learning with the assumption that there is an instructor in the loop. We assume they have access to a platform where they can work at their own speed, and a peer group with whome they are working. Finally, we based it on existing standards that have already been widely adopted and were in themselves very stable.
CC version 1.0 included cartdridge metadata - the description of the cartridge itself - and resource metadata - metadata associated with a resource in the package. We basically provided a means by which we could identify who the resource should be visible to, instructor or students. The default was that it would be visible to all. We had intended to use the 'invisible' element from Content Packaging, but this was already in use in different ways by the community, so we couldn't guarantee the results. So we used the resource metadata itself.
There is a whole range of content that can be placed in a cartridge: html, web links, media files, application files, etc. We also wanted to be able to include assessments in a cartridge. We went through an exercise with the publishers, asking them to review what question types they actually used. It became clear there were six basic types: multiple choice (single or multiple response), true/false, essay, fill-in-the-blank, and pattern match. Also, we introduced a discussion forum, and created a schema to introduce the discussion forum and integrate a group of users. And finally, content authorization to protect content - not DRM, but just a way for publishers to check that the licensing is being respected.
In CCv1.1 some changes were introduced. In roles metadata, we created the role of 'mentor' for parent. There is also use of a third role in other areas - the mentor could be an employer, for example. In higher ed, the mentor role might not be used - in any case where the mentor does not exist, content available for the mentor will be made available to the instructor.
Another area related to content in different languages, not only to present in different languages, but also, the content might be in different languages, as in a language-teaching resource. You define a prime language and secondary languages to be refrenced. Also, there was a request to include instructions for users to complete assessments. There is a rubric from QTI we use. Additionally, there is a rubric for the inclusion of curriculum standards (workshop on this tomorrow) across different regions of the world and different authorities. Also, there is the in clusion of the 'lesson plan' in the cartridge.
And finally, most importantly, there is the integration of LTI, which is the subject of today's seminars.
The actual spec defines unambiguous rules for building cartridges, describes additional constraints through the use of schemas, and offers two levels of testingcompliance for cartridges and for platforms. Common Cartridge does not define the runtime - there is an implied runtime, but we have stepped away from explicitly defining the internal operations of the platform. This allows vendors to more easily adapt to the spec.
The LTI incorporates the possibility of linking to services that may be run at the publisher's site. We can define this as just another resource in the cartridge. The same protocol can also be used for accessing eBooks and other kinds of services.
Core Cartridge metadata is defined in Dublin Core and mapped to IEEE LOM. Metadata resides in the imsmanifest file. It is not order-sensitive. Also, any requirement for a specific player by cartridge content must be declared in the Cartridge metadata.
At the level of resource metdata: roles metadata is associated with the resource, and restricts who the resource is assessible to, and restructs access. Curriculum metadata identifies learning objectives, addressed by a resource (samples of roles, curriculum metadata shown).
Conceptually, there are four kinds of content in a CC: "learner experience data", which is your traditional lesson content; "supplemental resources", which is additional material (including extra questions) an instructor can access during delivery; "operational data" explaining how the content behaves in the platform at runtime; and "descriptive metadata" which is the cartridge metadata describing the whole thing.
Compared to content packaging (CP) version 1.2 (CPv1.2) we decided to omit multiple organizations of content. We also removed the CP cartridge version characteristic object, so content package tools couldn't open cartridges - they must be opened by something that is cartridge-aware. Also deleted were sub-manifests, as well as inter-package links (ie., xpointer). Packages really need to be stand-alone in their own right.
We added things as well. For example, the root folder for shared content. Associated content in a learning application object directory. There is a schema for authorization data.
- diagram - links between resources and cartridges, allowed and disallowed
Assessments represent instances of QTI. They can embed any of the question types supported by the CCv1.0 profile of QTI. An assessment can contain a number of attributes, including number of attempts, time limits, and whether late submission is allowed. Cartridges offering feedback must support Yes/No and Distractor. The spec also, as mentioned, allows for a qticomment element (from the QTIv1.2 rubric) to allow for instructions on how to complete the assessment. (demo - qticomment element)
Question banks can be included, as an instance of the QTI objectbank. If one is included, only one can be included. You can embed any of the supported question types. While questions are used in assessments, thy cannot be referenced by other resources in the cartridge.
Finally, the Learning Tools Interoperability (LTI) specification allows tools to be launched and data to be returned to the LMS that launched the cartridge. (demo: basic LTIv1.0 description) It is a new resource time, an LTI call, and within that we can hold a description of how to access that service. In addition, eBooks can also be integrated in the same manner. So we can provide a reference to an eBook directly from the LMS, such that the reference points directly to the place in the eBook (section and page) relevant to the placement in the course. The publisher can therefore put a set of tokens into the cartridge that gives the correct reference into the eBook (this could be opaque, but at least one Publisher - Pearson - will make some references available as parsable strings). eBooks will be offered for this as a hosted service. And some publishers are bulding eBooks into applications, as resources accessible from the application.
There are two forms of authorization: one on the import of a cartridge (is this a valid site, does it have a license), and one on use, which is anonymous, and is authorization by PIN number. It is not foolproof; people can bypass it, but if they do, it is clearly done - it is perfectly visible that they intended to do it. Authoization is via an authorization server - for the import, you go to a single source (the assumption is that the cartridge is covered by a single license).
The Common Cartridge Alliance is dedicated to achieving adoption. We have the specification, and will some have version 1.1, as well as a tool for profiling IMS specifications (ScehmaProf) for profiling IMS (and other) specifications. There is a profile registry, so people can submit profiles and share them. We actually have cases where people independent of us have used SchemaProf. There is a compliance program to help people adopt to the spec (the end-user community is tired of hearing excuses about why they can't import content from different people). There is a collaboration program and a CC forum (the Common Cartridge Alliance website is http://www.imsglobal.org/cc/alliance.html but you must be a paid subscriber to access the forum).
There is a compliance program and a mark you can use for recognized compliant resources (you have to be a paid-up member to comply). There is a directory of resources: http://www.imsglobal.org/productdirectory/directory.cfm Also, JISC has created a 'transcoder' that created common cartridges from other types of resource. http://www.jisc.ac.uk/whatwedo/projects/transcoder.aspx
IMS Workshop Notes - Chuck Severance
Homework (to do while you're ignoring the lecture):
1. Join the developers network (free): http://tinyurl.com/imsdn-forum
We talk about code & move code around, but not about the spec itself. It requires a free IMS community account.
2. Make sure you can edit text documents without messing them up. That is, no MS-Word or anything like that imposes formatting. Use BBEdit, TextMate, TextWrangler, etc.
3. Decide whether you're going to use Java or PhP (or both). Unless you are an experienced servlet developer in Java, use PHP.
4. Install PHP - use XAmpp
5. Unzip the PHP from the DVD into the directory and test your install. From
http://code.google.com/p/ims-dev/
Get the latest handout: http://www.dr-chuck/ims
Learning Tools Interoperability
We have htree major types of LTI:
- Simple LTI - not a formal spect - May 2008
- Basic LTI - launch plus outcomes part of IMS common cartridge 1.1
- Full LTI - end of 2009
Basic LTI is a profile of LTI 2.0 - the focus is on launch and LTI integration. As we saw yesterday, the user experience is to click on the link and see the tool. The LTI tool is a proxy tool inside the LMS (so the link is internal to the LMS) which posts a form with learner and a secret and then forwards it to the vendor site, which verifies the secret and sends a cookie with a session and a redirect, which opens the service.
It's very simple to write for; it's simply REST-based. You basically get four kinds of information sent on every request:
- the LTI version number
- resource link ID - the LMSs representation of the resource
- user ID - an opaque string, from the LMS, with no identifying information
- roles - we just take the roles from LIS (Learner Information) - assume that tools key off 'instructor' string, otherwise you're a non-instructor
- a bunch of data pieces from LIS (we used underscores because many systems don't like dashes): lis_person_name_full, lis_person_contact_emailprimary, lis_person_sourced_id, context_id, context_title, tool_consumer_instance_guid (this is the instance of the LMS, your LMS's domain name), tool_consumer_instance_description (this the description of your LMS).
Some of these data elements are optional. For example, an LMS might not decide to send the person's name. The whole LTI is designed to be 'sandboxable'. The absolute minimum ser is LTI version, resource_link_id, and (maybe) context ID.
Basic LTI in Common Cartridge: the basic idea is that, in the Cartridge Use case, the publisher wants to point to something:
- so you need the URL
- then there are custom parameters (not to be messed with by the LMS) - the LMS parameters are under 'extensions'. They can embed context information, version info, etc., whatever they want. The idea is, whatever they put in here, they will get back when the cartridge loads (if they need to ensure it's the same, they can encode it).
- the extensions are generated by the LMS and are namespaced by the LMS. For example, Sakai might send the frame-height, or some other LMS-specific information.
- vendor - some human-readable info about the vendor.
The basic LTI security model is based on OAuth. See http://www.oauth.net It signs messages using time-stamp, nonce. We use trust between pairs of servers. Maybe one day there will be three-legged OAuth in order to support identity servers or third-parties (like Twitter). We're not going to try to communicate to you through some kind of third party identity who the user is.
The tool decides the level of security. It may require all the security values, or none of them. So, for example, it could check time skew (how old the request is) and nonces (there is literally no way to alter them, so there's no man-in-the-middle problem). See http://www.intertwingly.net/blog/1585.htmlOauth depends on reasonably long secret - a 4-charactr pin isn't very secret. You want them long, ugly and nasty. Right now, they are hand-delivered ("passed out-of-band"). There are two levels of secrets: the site-wide password, and the resource-level password: an individual license or one-course license. Note: ou don't have to have either or both.
The LMS admin calls the tool provider, the provider generates a secret, and keys it in over the phone. Inside the LMS there will be some list of providers and passwords (with an editing screen to change them). The resource-level secret is assigned by URL, resource key, and secret. The LMS Secret implies that the user_id and course_id values are the same from launch to launch. But with the resource level secrets, values such as user_id and course_id in launches should be modelled linked to the resource or key.
(Description of OAuth - *way* too fast to follow if you didn't already know the spec - I'll cover this in a later post).
OAuth implementation patters: we create an array or property bag of parameters and pass it to OAuth to sign. Then we send the signed data. The tool receives the post, calls OAuth to pull the data from the request, and asks OAuth to validate it. OAuth calls your 'store' for lookup kys, etc. The pattern is, you put all this into a form, and then you press the submit button (you have to deal with the case where Javascript is turned off, so you have to include the submit button in the basic configuration, or a bit of clever Javascript that will emulate a button-push). You hand the form to OAuth, which processes it, and if it is approved, you do stuff with it. If it is rejected, you return to the launch_presentation_return_url.
Basic LTI depends on IMS Tools Interoperability for support of outcomes. It's a very simple message signature. If my LMS supports outcomes, I include a field that is defined to support outcomes. All I send is the outcome and the tool launch ID. The security is separately established between tool and LMS. The tool vendor has to receive out-of-band authorization to set data (send outcomes) back to the LMS. Very simple, not very complete.
I (Chuck) added an appendix on LTI outcomes recommendations. There may be some discussion on this - conversation in the room on how to report outcomes (eg., grades). Maybe some XML? (Sounds like Wilbert speaking). We're not replicating CMI or SCORM tracking. If people what to get together and exchange data, fine. The work for outcomes in the full LTI is still under development.
The sample code is available at http://code.google.com/p/ims-dev/
org.imsglobalorg.basiclti.BasicCTIUtil.java
blti.util.php
It is wide open, and you can become a committer to this code; I will probably change the Apache committer document and change it to IMS.
Afternoon (Chuck Severance)
Working with the sample Java and PHP implementations.
http://code.google.com/p/ims-dev/
Use my oauth code, not theirs - I have caught flaws in their code.
org.imsglobalorg.basiclti.BasicCTIUtil.java
blti.util.php
There's no LMS-specific code in there, and any LMS can use this code.
There are four basic methods in the code:
- validate - take a look at a descriptor out of a cartridge and validate it
- parse - parsing the descriptor - looks at the XML and extracts the data
- sign - signing method - merge these properties with LMS data, secret, etc. Returns properties with oauth junk in it.
- post - pass the properties to (??)
Some activities are using some code. A building block from Alan bery, U. Amsterdam. Stephen Vickers, eg. http://projects.oscelot.org/gf/project/ ...
Also - JSR portlet for Sakai (maybe available in version 2,7) and planned for Moodle 2.0 (and a backport for 1,9 and 1.8) - developers are working on it. Or Pythn - www.tsugiproject.org - my take on a personal learning environment. It talks a number of sifferent protocols - simple LTI, basic LTI, facebook and Google.
(various other exercises and tests - sorry this is pretty random at the end here, but we went through all the code - I'll analyze and have more on this in the future - I have working versions of all the code and have been through it messing around with it.).
Comments
Post a Comment
Your comments will be moderated. Sorry, but it's not a nice world out there.