The imsld package is a .LRN service (or package, we use these terms indifferently in this specification when referring to .LRN), wich will interact with some other .LRN services. When writing this specification, we expect the imsld package to interact with at least the following .LRN packages:
Forums.
Jabber.
Assessment.
Evaluation (grade book).
Calendar.
News.
FAQ
Notifications.
File Storage.
As we mentioned earlier, the imsld package allows to easily modify the mappings between the elemnts of the IMS LD specification and the .LRN services. And not only modifying the mappings, but also to add new ones. By these way if the IMS LD specification change in some aspect, then the package will addapt to the new changes easily. From our point of view it is necessary that in the future the IMS LD specification will add more tags that univoquily mapping with services. By these way compatibility between LMS are obtained, and if an LMS doesn't understand one tag because it is not available, then it will be ignored and nothing will be presented to the user.
Besides, we take advantage of the new callbacks used in OpenACS in order to provide a clean interaction between different .LRN packages. With the callbacks we can determine if some needed package is not installed, and instead of displaying an error to the user, try to map the activity or whatever we are mapping to other package, and if after trying with all the available packages we can't map the item to .LRN, a message is shown to the user with this and any other item that coud not be mapped by the system and with the purpose of leting the user to do the manual mapping.
We have to take into account that the item will not allways have all the necessary information to let the mapping be done easily, but we try to do our best by providing at least the required information to create the forum, chat, assessment, task, etc, and if definetively no mapping can be done, a final error message is shown to the user indicating that there is at least one item that .LRN can't understand.
When writing this specification, we were not thinking about + implementing an IMS-LD editor in the short term. We think that in the + market there are already very good IMS-LD editors, and that instead of + investing efforts and resources in doing one more, we better work in order + to provide a good IMS-LD player and a viewer.
In the future we might work on an editor, but now there is a greater + need of a good player. We therefore provide support for the most commonly + used IMS-LD editors (Reload, Coppercore and LAMS), which we mentioned + above. Even tough there is a standard, there is always something different + in the way each editor makes use of it, and we try to deal with it by + being as flexible as possible, even tough sometimes it is hard to + achieve.