Here we give an explanation of the way the inner components of the imsld package interact internally between them and externally with some other packages of .LRN Next, a figure about the general architecture about IMS LD and the ims-ld package is shown.
We have two methods for loading the information into the ims-ld package. One is by means of an internal .LRN editor (as we said this is not planned for the short term). The other method is loading an IMS LD compliant XML file, as we said before, it can be generated using an authoring tool wich is not part of .LRN, at least not when writing this specification. The file is requested to the user by the UI of the parser. This UI will conist of a small number of pages with a form where the user can upload the file and with some others with error or log messages displayed to the user via web. In this step, the imsld package will also validate the IMS LD file for proving conformance with the IMS LD standard. It indicates when the parser didn't parse the whole file correctly and it needs human help in order to finish its job. So, the first component of the imsld package that interacts with the database is the parser, using the tcl and sql API.
At the lowest level we have the information stored in the data base. The information that have been loaded from an IMS LD file is parsed and stored in the database in the tables related to the level A, B and C that have been shown in the previous Data Model Section. With this mapping we will have all the information contained from the IMS LD package in the .LRN
Once all the information of the IMS LD compliant XML file is stored in the database, the course is ready to be played. As we mentioned above, the player has two modes for the professor, on-line and off-line. The first one is the off-line mode, because the course has not being played or instanced yet. In the off-line mode the teacher should associate the students and course admins to their respective roles in the unit of learning. In this step are fullfilled the tables imsld_party_roles_map and imsld_parties_property_values_map. Also the rest of the tables of the run tables are initialized for each user at this time. All the information that is stored in this Run Tables is not contained in the IMS LD file, this information is particular for each run. At this step the information is particularized for the users of the unit of learning.
Be aware that a professor can have the student role in the unit of learning or vice versa, that is the professor's choice. The roles of the unit of learning are stored in the database, but the mappings between the real users with their respectives roles is the professor's task. When doing these mappings, the respective conditions recently obtained from the XML file start to be verified. For instance, there is a max-number-of-persons tag for a role, so the professor can't assign more than n users to that role. There is also a match-person tag, that implies that the person with that role can't have any other role inside the unit of leaning while being assigned to the first role. In this off-line mode, the professor can take a general perspective of the unit of learning. He/she can take a look at all the activities that will be done by the students, as well as the conditions and every information that is important to be shown.
Once the real users are mapped to the roles, the unit of learning can be instantiated. This will start the on-line mode of the viewer.
For the professor, the on-line mode of the viewer lets him/her to see the status of the course(unit of learning). As mentioned in the user requirements chapter, this mode of the viewer lets the professor to do any tracking activity of the students. Such as seeing how many students are in what act of the play, what user-choice activities are being accessed and what aren't, etc. By the time when writing this specification, the professor can't modify anything from the viewer, it is read only information. At the time of run of the unit of learning the Run Tables are refreshed with new completed activities, acts and plays of each user.
For the student, the on-line mode of the viewer is very similar to the one for the professor, with the main difference that with the student can only see his/her own information, whereas the professor can see the information of all the class students. From the viewer the students can see what activities have already completed, as well as how much time between activities they took, and how much time they spent in each activity. In some designs (of the IMS LD compliant XML file), the student can see the rest of activities that he/she has to complete in order to finish the unit of learning. This is not true in every case, because, for instance, when creating the unit of learning, the professor can set the is-visible tag to false for every activity in the unit of learning, not allowing the students to see any more than what they have already done.
Everything is ready now for the most important component of the imsld package: The Player. Of course, the viewer will be allways accessible to the class members, so they can interact with the player and then with the viewer, any time they want and in any sequence.
The player, from the visualization point of view, is nothing more tan a cetralized page. This centralized page has some menus and message sections at the sides and at the bottom, with instructions and descriptions that the student has to read. The professor can be part of the unit of learning being played too, the only thing he/she has to do is assign him/herself to a role of the unit of learning.
The player is the component that is in charge of verifying the poperties and conditions that were specified in the XML file. It will detect wichever change in the properties, check the completion of activities, acts, etc. and evaluate the conditions. In particular the properties that at least the ims-ld package is going to support are:
Global user properties. These type of properties are as the nationality, user model, etc.
Properties selected by the user when navigation throuh html page. The user can select different values and this became properties. Depending on the values selected by the user, he/she can go through different paths in the course. For this option is necesary that the player understand HTML modified with some IMS LD properties in order to enable this
Properties that are the result of an evaluation or an assessment. Depending on the values of the evaluation or assessment, he/she can go through different paths in the course.
Every time that for wichever user a resource is served, an activity is started or completed, an assessment is finished, etc, the player must check for every possible condition in order to follow the worklow defined by the unit of learning. The player is also the one in charge of changing the corresponding property values of each resource and to make sure that the workflow of the course is the one the course creator intended.
Moreover, the player is the component that interacts with the .LRN packages mentioned before. It make use of them in order to interact with the users. The information about every resource is stored in the database by the parser, but the actual interaction happens when the player finds out that a given resource has to be instanciated and shown to the user. This is then the intercomunication between .LRN packages takes place. As mentioned before, in order to make this intercomunication as clean as possible, we will make use of the callbacks functionallity. Using callbacks is the best way of intercomunicating .LRN packages, because we don't have to rewrite the code and we can verify if two packages are connected. Besides, we can't depend on the packages that are not required by .LRN. In fact, we can't assume that any package is installed, because we don't know how the site wide admin configured the .LRN service. Tha is something that the player is aware of.
This is a detailed explanation of what .LRN packages and for what resources we will use:
Forums. To deal with the asynchronous IMS LD defined services. More specifically, it will deal with the <conference> IMS LD tag, when conference-type is asynchronous.
Jabber. To deal with the synchronous IMS LD services. More specifically, it will deal with the <conference> IMS LD tag, when conference-type is synchronous.
Assessment. To deal with activities in which enviroment has a QTI resource or a reference to an assessment. Therefore, whichever QTI file or a predefined reference to an assessment will be interpreted by the assessment module.
Evaluation (grade book). We will have an standard way in order to recognize that Evaluation package should be invoked when interpreting an IMS LD file. This is not mentioned in the IMS LD specification so it is an adaptation to our LMS system. So we have to stablish a new propietary criterion: A necessary condition for launching the Evaluation package will be that we would have two associated resources together in the same act with a concrete reference to the evaluation package. One resource inside an enviroment of a learning activity (usually for students) and the other resource for a support activity (usually for a professor). When the consensued href for evaluation arrives, then the ims ld package will be launched and the professor will parametrize a new exam, file to submit, homework, etc. with its respective mark load if proceeds. On the other hand the student will be able to upload his/her solution. But another necessary condition will be that there would be in the following act another two associated resources together: one for the professor in order to be able to mark and evaluate his/her work, and other for the students that will receive the results and comments for the professor and should study them. As we can see there are really 4 different resources that could be in 4 different activities.
Calendar. We will have an standard way in the IMS LD package in order to recongnize that the Calendar package should be invoked. Some activities can require as a resource to see dates or/and notes in a Calendar or to put them in it.
News. To deal with the announcements. More specifically, it will deal with the <conference> IMS LD tag, when conference-type is announcement.
FAQ We will have an standard way in the IMS LD package in order to recognize that the FAQ package should be invoked. When the package is invoked then a set of FAQ will be presented to the student.
Notifications. The system will generate notifications in the form of emails for all the users of the learning experience or for particular roles, and also the different applications will communicate in order to advice about some events
File Storage. The IMS LD can refer to an existing resource (file or URL) of the File Storage. Although, the more usual case is that if we want to refer to some files, then the files will go inside the IMS LD package instead of being a reference to the File Storage.
What specific funcions of each package we use will be defined during the development phase.