Here we give an explanation of the way the inner components of the IMS-LD 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 which 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 consist 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 IMS-LD 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 IMS-LD 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 fulfilled the tables IMS-LD_party_roles_map and IMS-LD_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 respective 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 IMS-LD package: The Player. Of course, the viewer will be always 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 centralized 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 properties and conditions that were specified in the XML file. It will detect whichever 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 through 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 necessary 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 whichever 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 instantiated and shown to the user. This is then the intercommunication between .LRN packages takes place. As mentioned before, in order to make this intercommunication as clean as possible, we will make use of the callbacks functionality. 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. That 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 environment 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 establish a new proprietary 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 environment of a learning activity (usually for students) and the other resource for a support activity (usually for a professor). When the agreed 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 recognize 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 functions of each package we use will be defined during the development phase.