Domain Course File¶
- Domain Course File
- Course Content
This document contains information about the domain course file and its format. A domain course file is an XML file which contains the information needed to follow a single course which may contain one or more lessons. A lesson is given via a training application (e.g., VBS, Powerpoint) and assessed by a Domain Knowledge File (DKF) (refer to GIFT GIFT Domain Knowledge File for more information). The course file is read by GIFT and used by the Domain module.
The explanation below details how the course file is parsed and offers insight into how you can author new files or customize existing ones.
Important and quick reference information can be found in the shaded boxes throughout this document.
The course schema describes the format of the xml document in terms of constraints on the structure and content.
Schema location: GIFT\config\domain\course\course.xsd
The course.xsd file is useful for creating new entries in a course file, in addition to creating one from scratch. The schema is also used by jaxb to generate java classes for use by GIFT.
For more information about JAXB:
There is also a binding file (binding.xml) that is used to customize the generated classes.
Editing the Schema¶
In certain instances, such as when a new transition (e.g., Guidance, Present Survey) is created in GIFT, you will want to edit the xsd in order to allow a course file to use that newly created element. There are dozens of xsd editors available to help with this effort.
After the xsd is finished being edited, build GIFT to generate the java classes (GIFT\generated\) and the jaxb jar used by GIFT.
Once the jar has been created/updated, the generated java classes associated with the changes made in the schema will be available for use in GIFT source development.
There are two forms of course file content validation, one using the xsd and the other using domain initialization logic scattered throughout the domain modules. The quickest way to validate a course file is to use the Course Authoring Tool (CAT) to validate against the schema and then validate using Domain module logic. For more information on the CAT refer to Course Content (top-level) section or GIFT XML Authoring Tools.
This section describes the top level elements of the course file.
Currently, course files are authored by either directly editing the XML content using a text editor (should only be used by experienced GIFT developers), or the preferred method of using the Course Authoring Tool (CAT). This is the dedicated Course -authoring software tool with a high-level user-friendly interface that will shield the author from some of the low level details of XML editing. The suite of GIFT authoring tools is not an end all solution but rather a quick and simple solution that allows the user to develop and validate configuration files for GIFT without a simple text editor. Furthermore, the tools prevent the user from having to launch GIFT modules and possibly enter into a domain session just to validate configuration content.
The course name element specifies the display name of the course. This label is displayed to the learner on the Course selection page of the Tutor User Interface (TUI).
The transitions section describes the flow of the course in a single domain session. There are several types of entries that can be used to describe the flow (below). There are no limits to the amount of transitions or the ordering.
Every transition has an optional transition name element. The transition name value makes it easier to identify transitions rather than simply saying “the 7th transition” in the list of transitions.
Helps guide the learner by presenting content on the TUI.
- Content Type choice:
- Message –information to present
- address – the URL of content to present (e.g. html page)
- message (optional) – information such as guidance that could be used to help direct the user on what to do with the URL content being presented.
- HTML – a local html file to present.
- Display Time (optional) – Used to specify how long the message will be presented to the user (seconds). If the display time is not provided, a button is shown to the user to allow them to advance to the next transition at their own pace.
- Full Screen (optional) – Whether or not to display the guidance content in full screen mode in the tutor user interface (TUI). By default this value is false and the guidance will be presented in the vertical panel of the TUI.
This transition causes a survey (pre-test, post-test, user assessment) to be presented to the learner.Survey Type Choice:
- GIFT Survey – Surveys are referenced by the GIFT survey key value (for more information on survey keys refer to GIFT Survey Authoring System Instructions).
- AutoTutor Session – Uses an AutoTutor script to guide and/or query the user for information. The session is assessed using a DKF.
Lesson Material¶This transition specifies that training material should be presented to the learner on the TUI. This can be specified in two ways for a course file:
- List – specify the training material references inline to this course file XML content.
- Files – specify lesson material XML files that contain references to training material. These “external” files can be used to share lesson material references across courses/domains. For example, the TSP 07-GFT-0137 vignette courses, available upon request, use the same lesson material XML file.
- Helpful Information
- YouTube Videos – in order to reference a YouTube video as lesson material you will have to follow the steps below to convert the raw http address provided by YouTube into an GIFT supported address (i.e. an address conforming to the HTML iframe format because lesson material is presented within an iframe in the GIFT TUI).
An example of using a YouTube video address can be found in Domain\VBS.PresencePatrol.Scenario\Presence Patrol.lessonMaterial.xml (which is used/referenced by Domain\VBS.PresencePatrol.Scenario\Presence Patrol (Sara).course.xml).
1) Copy the YouTube 11 digit video ID (e.g. jciijU8Mj_Y).
2) Go to http://web-wall.blogspot.com/2011/09/youtube-iframe-api-customiser.html
3) Paste the YouTube ID into the appropriate textfield.
4) Answer the various Yes/No questions presented based on your needs.
5) Copy the "src" value. For example, my iframe value looks like this:
<iframe width="560" height="349" src="http://www.youtube.com/embed/jciijU8Mj_Y?rel=0&autohide=1&autoplay=1&controls=0" frameborder="0" allowfullscreen="0"></iframe>
Therefore I would copy this: http://www.youtube.com/embed/jciijU8Mj_Y?rel=0&autohide=1&autoplay=1&controls=0
Note: If there is one or more &'s in your src value you will need to replace each with "&" to be XML compliant.
Therefore my value would look like: http://www.youtube.com/embed/jciijU8Mj_Y?rel=0&autohide=1&autoplay=1&controls=0
6) Use the value as the "URI" in the course (i.e. paste the value in the URI field in the GIFT course authoring tool).
In the future we hope to automate this process inside the GIFT authoring tool(s).
This transition is used when the training application is needed.
- dkfRef – provide the DKF (relative to the Domain directory) that will be used to configure the assessment logic for the lesson given in the training application.
- options (optional) – these are training application options
- disable instructional strategies (optional) – whether or not to ignore instructional strategies during the execution of this lesson. This is useful for when you want a user to receive no tutoring help.
- Show avatar initially (optional) – normally the avatar (if configured and instructional strategies are called upon that use the avatar) will only appear when needed. Setting this value will force the avatar to appear at the beginning of this lesson, even if it isn’t actively doing anything productive when initially shown.
- Avatar – provide the Media Semantics avatar html file that describes the presentation of the character to show.
- interop - list the Gateway module interop connections needed to communicate with the training application in order to facilitate the assessment of the user’s actions (e.g., DIS entity state PDUs) and possible automation of the training application (VBS scripting). For information on launching your own training application and building your own interop interface refer to Authoring Guide, GIFT Configuration Settings and GIFT/config/gateway/interopConfig.xsd, as well as the Gateway module package.
In addition there maybe Interop inputs (i.e., arguments) needed at various stages of executing a lesson in a training application. For example, the VBSInteropInputs contains a loadArgs element which has the name of the VBS scenario. In this instance, the load arguments are sent from the Domain module to the Gateway module when the Siman.Load message is sent.
- Guidance (optional) – same as Guidance under transitions with one exception:
- Display Time (optional) – Used to specify how long the message will be presented to the user (seconds). If the display time is not provided, a default time based on the length of the message is used.
- finishedWhen – specifies when the training application transition is complete and the next transitions should be used. Currently the possible values are the training application states (TrainingApplicationStateEnum.java).
This transition is used to present After Action Review content. AAR content is populated by DKF performance node scoring information.
Note: Survey results and DKF scoring information populates AAR information. If the DKF don’t contain optional scoring information, no entries relating to performance assessments will be shown in the AAR.
Merrill’s Branch Point¶
A Merrill Branch Point introduces dynamic course flow into a GIFT course. As of know there are no known limitations to the number of branch points in a course. Currently the flow through Merrill’s quadrants (Rule, Example, Recall and Practice) is fixed and the domain content is dynamically chosen based on learner state characteristics at the time a quadrant is entered. This is done using a combination of macro and micro adaptive pedagogy (“eM2AP”), and domain content metadata and paradata files. In between each fixed quadrant the author is free to insert as many course transitions as they would like such as surveys that can be scored to alter the learner’s state and therefore change the presented domain content.
Survey Context value references the survey context unique key for this course. The survey context contains all the surveys used during the course in a domain session, more specifically the surveys presented during the Present Survey transitions and not surveys given during a lesson in a training application. More about survey context can be found by reading the GIFT Survey Authoring System Instructions or viewing the UMS database. Generally, Surveys, composed of one or more questions (with or without answers/scoring), are part of a Survey Context (group of surveys).
Note: One or more survey context references can be used in a course by specifying one unique survey context in the course XML file and different survey context references in the DKFs used during a lesson in a training application transition.
The version attribute is now in all XML files that can be authored using one of the GIFT authoring tools. It provides a mechanism to better pinpoint when a particular instance of a GIFT authored XML file was saved. If the author used one of the authoring tools to save the file, the tool will auto-increment minor version number (it can also update the major version, e.g. 2.0.15 to 3.0.1).
The course description element is where the author can provide information about the course. This could include (but is not limited too) a domain description, course objectives and training applications used.
This value indicates whether or not to prevent this course from showing up in the list of courses in the tutor user interface. By default all courses are shown to the user but in the future only certain courses maybe presented to users based on various aspects such as learning history.
Because you are free to author your own course using the offered transitions, there are some things to consider when selecting and ordering transitions.
AAR (After Action Review)¶
- AAR transition should be after a Training Application transition. When an AAR transition is called upon it will show the AAR for all previous Training Applications up to that point in the current domain session. If there weren’t any Training Application transitions there would be nothing to display to the learner.
- AAR transitions should not be followed directly with another AAR transitions. This is probably the only transition where it doesn’t make logical sense to have them back to back.