SLD 2.0 Implementation Guide

Size: px

Start display at page:

Download "SLD 2.0 Implementation Guide"

Kellie Phelps
5 years ago
Views:

1 SLD 2.0 Implementation Guide Guillaume Durand Luc Belliveau Benoit Lanteigne Ben Craig Version Page 1 of 8

2 Table of Contents 1 Introduction Requirements for implementation Roles Quiz scores and activity variables Constraints Choices Workflow engine SLD to WF engine translation The.Net Workflow implementation of SLD Net Workflow XAML Custom Library of Workflow Activities SLD to XAML Translation Running the Learning Design Workflow Acknowledgement Table of Figures... 8 Page 2 of 8

3 1 Introduction This document introduces SLD 2.0 and is intended for people interested in implementing the specification. It would be useful to also read the SLD 2.0 XML Binding document. 2 Requirements for implementation 2.1 Roles Each SLD 2.0 scenario requires a set of roles. These roles are local; they are used to attribute activities to the performers. For example let s considerer Paul is a student within the course management system, he enrols in a learning activity defined by an SLD scenario. The teacher (LMS) assigns Paul the role studentleader. During the learning activity Paul will perform the activities of a studentleader. His role in the LMS does not change, he remains a student. During the enrolment of the students in the activity, assigning them roles as defined in SLD is mandatory. 2.2 Quiz scores and activity variables SLD splits a learning activity in activities and choices. In order to define constraints on the activities and conditions for the choices a set of variables are required: - $activityresult: The score obtained by the user at the last activity. - $activityduration: The duration of the current activity. - $actorsaccessedcount: Number of users who have accessed the current activity. - $actorsparticipatedcount: Number of users participating (being active) in the current activity. - $totalactors: Total number of possible users for the current activity. (Branching is considered) All these variables are integers except for $activityresult which is determined by the activity. These values must be set by the Learning Management System and the workflow needs to have access to these values. The workflow must be able to evaluate conditions based on these values in order to determine branching inside of the workflow. The LMS must also be able to track time in order for $activityduration to work properly. Particular attention must be given to the $totalactors variable. Since branches can change the total number of possible actors and it is impossible to predict accurately until runtime, the LMS/Workflow engine must ensure that conditions based on the $totalactors variable cannot continue until the activities have been synchronized. That is to say that all decisions required to evaluate the $totalactors variable have been completed. The implementation of synchronization may vary from LMS to LMS; but included below is a suggested implementation of synchronization of the $totalactors variable for SLD. Page 3 of 8

4 All <activity> and <choice> elements should be assigned a synchronization ID and depth. The synchronization ID must increment based on the position of the element in the SLD document. The depth must indicate numerically the parent/child relationships. Each activity must specify to which ID it synchronizes with whenever its depth is greater than 1; we ll call this Sync On. If the activity has a preceding sibling, the Sync On value becomes the ID of the preceding sibling; otherwise it becomes the ID of the parent <choice> element. Example: <choice> <when..> <choice> </choice> </when> <when..> </when> </choice> Synchronization ID=1, Depth=1 Synchronization ID =2, Depth=1 Synchronization ID =3, Depth=1 Synchronization ID =4, Depth=2, Sync On=3 Synchronization ID =5, Depth=2 Synchronization ID =6, Depth=3, Sync On=5 Synchronization ID =7, Depth=2, Sync On=4 Synchronization ID =8, Depth=2, Sync On=3 Synchronization ID =9, Depth=1 Additionally the player must keep track of each actor and their current activity synchronization ID; we ll call this Current ID. When a condition using $totalactors is encountered and the depth of that activity is greater than 1, the condition must always evaluate as false until the value of the Current ID for each actor is greater than the value of Sync On for the activity evaluating the condition. Once this condition is met, the activities are synchronized, and the evaluation can occur normally. Below are examples of how to retrieve these values using XSLT. Synchronization ID : count(preceding::sld:activity) + count(preceding::sld:choice) + count(ancestor::sld:activity) + count(ancestor::sld:choice) + 1 Depth: count(ancestor::sld:choice) + 1 Sync On (if count(ancestor::sld:choice)+1 > 1): count(ancestor::sld:choice[1]/preceding::sld:activity) + count(ancestor::sld:choice[1]/preceding::sld:choice) + count(ancestor::sld:choice[1]/ancestor::sld:activity) + count(ancestor::sld:choice[1]/ancestor::sld:choice) + 1 Page 4 of 8

5 2.3 Constraints SLD has different types of constraints on activities; the LMS or Workflow engine must honour the following constraints on activities. Must Terminate this constraint is used to enforce an activity to end within a certain time limit or condition. For example a quiz activity may need to end after 30 minutes. The learning design player must disable the quiz after this time. Cannot Start this constraint is used to prevent an activity from starting. The users must wait until a certain condition has been met before they can start the activity. For example you may want all students to enter a chat room before students can start chatting. Cannot Continue this constraint is used to prevent a user from going onto the next activity in the learning design. This can be used in group activities where all students must finish their portion before the group can continue onto the next activity. All constraints are based on a condition; these conditions are typically based on the variables defined in section 2.2. It is important to note that constraints have different meanings depending on whether the activity is marked as single or group. For instance, if a quiz marked as single has a Must Terminate constraint based on a 15 minute duration, each actor has 15 minutes to complete the quiz; however a quiz marked as group with the same constraint would end 15 minutes after the quiz was first started because the constraint applies to the group. 2.4 Choices The workflow engine must be able to support branching. SLD can express many different execution paths based on the choice tag. For example the result of a quiz may direct the student to do a catch-up summary if they score low. If a student scores high on the quiz you may want them to do a different exercise. 2.5 Workflow engine In order to play a learning activity defined in SLD 2.0, a workflow engine is highly recommended. There are many existing work flow engines capable of handling SLD. In order to play learning activities, the workflow has to support the following features: State-based workflows - the system could work with a sequential workflow except it may be difficult to freely traverse the workflow. (i.e. going back to a previous state) Conditional Branches a decision or choice will be required in some activities therefore we need a way to handle branching. Simple If-else-then branches will work. A rule engine the conditional branches are evaluated using declarative rules. Since the rules can change constantly we need to use a rule engine. The rule engine is also used to evaluate the user s current role and is to synchronize activities. Event detection the workflow moves between states using an event-driven architecture. When a workflow receives an event it will check the event and then it can transition to a new state if required. Page 5 of 8

6 Workflow synchronization and workflow communications SLD supports group activities and in order to synchronize these group activities workflows need to communicate with each other. For example when all students finish a group activity the teacher must know about it. Whatever will be chosen as a workflow engine, it is more than likely that it won t be able to read a SLD scenario and to play it right away. A translator from SLD to the WF language is required. 2.6 SLD to WF engine translation The translation from SLD to the WF engine language can be made with an XSLT or using XML libraries to directly handle the XML in the application code. Depending on the workflow engine used, the SLD scenario may create more than one workflow definition output file. XSLT 2.0 has built-in support for multiple output files. If XSLT 1.0 is used it would either need to be extended to support multiple files, or the output document needs to be parsed to separate the pertinent information. 3 The.Net Workflow implementation of SLD Net Workflow The.Net workflow engine is able to manage multiple executing instances of workflows at one time. The workflow runtime engine creates each workflow as an asynchronous thread and the workflow engine is able to schedule when each workflow runs. Our web based implementation requires a different scheduler provided by.net so each workflow instance does not run in its own thread. It is possible to plug-in a different scheduler for the workflow engine if the default scheduler is not sufficient. During workflow execution, each workflow will go through a series of states. For example, all workflows start in the created state and then move into the running state when execution begins. The workflow can also go into states such as suspended, terminated, or completed. Other events associated with a workflow such as idled, persisted, loaded, or unloaded are possible. The runtime engine manages the life and death of each workflow. Like the scheduler the runtime engine can be replaced by a customized one. 3.2 XAML XAML is a XML based language used extensively in.net Framework 3.0+ technologies, particularly Windows Presentation Foundation (WPF) and Windows Workflow Foundation (WF). In WPF, XAML is used as a user interface mark-up language to define UI elements, data binding, events, and other features. In WF, workflows can be defined using XAML. When used in WPF, a XAML file can be compiled into a.baml (Binary XAML) file, which may be inserted as a resource into a.net Framework assembly. At run-time, the framework engine extracts the.baml file from assembly resources, parses it, and creates a corresponding WPF visual tree or workflow. When used in WF, contexts, XAML is used to describe potentially long-running declarative logic, such as those created by process modeling tools and rules systems. The serialization format for workflows was Page 6 of 8

7 previously called XOML, to differentiate it from UI mark-up use of XAML, but now they are no longer distinguished. However, the file extension for files containing the workflow mark-up is still "XOML". 3.3 Custom Library of Workflow Activities The implementation of SLD requires a set of customized workflow activities. These workflow activities can be directly called by the XAML. The custom activities are needed to modify routine workflow activities. The.NET workflow engine is highly customizable through these customized activities. For example a sample custom activity could be to calculate the score of a quiz. The XAML definition is customized to meet the exact implementation. 3.4 SLD to XAML Translation To translate SLD in XAML we have tried two languages independently. XSLT 2.0 and XSLT 1.0. SLD XSLT XAML Figure 1: SLD to XAML translation Translation using XSLT 2.0 is more convenient since SLD to XAML requires multiple output files. The translation from SLD to XAML requires the generation of a workflow definition file and many rule files. The implementation using XSLT 1.0 requires a 2 stage translation technique. The first stage parses the SLD into XAML workflow definition and many XAML rule definitions into a single XML file. The second stage splits this single XML file into a workflow definition file and separate rule files using the.net XML parser. 3.5 Running the Learning Design Workflow The first step consists in creating a workflow definition using the XSLT translator. The Common Cartridge- SLD 1 input file is given as an input to the XSLT translator to be translated into a XAML workflow definition and rule definition. The player was developed in a.net learning management system. The player loads the XAML definition and starts the workflow engine. The users interact with the workflow via a user interface that generates events. The workflow engine receives these events allowing it to transition to the different states inside of the workflow. 4 Acknowledgement This work is part of the SynergiC3 project ( which is partially funded by the Atlantic Canada Opportunities Agency s Atlantic Innovation Fund (AIF), a program designed to encourage 1 An example of a IMS-CC manifest file included SLD is provided in the XML Binding Document (section 5) Page 7 of 8

8 partnerships among private sector firms, universities, colleges and other research institutions to develop new products and services. The SynergiC3 project is a Research and Development collaboration between the National Research Council of Canada, Université de Moncton and Desire2Learn Incorporated. 5 Table of Figures Figure 1: SLD To XAML translation... 7 Page 8 of 8

Dot Net Framework 4.0: Advanced Microsoft C#.NET Web Development

Dot Net Framework 4.0: Advanced Microsoft C#.NET Web Development Duration: 90 Hours What you will learn This course is your first step towards success as a Dot Net professional, designed to give you a