We refer to the term "DiglibPackage" as packages that have been published in Diglib, and modified for use. These packages are always IMS packages with a single file, the imsmanifest.xml. This IMS package is a generated package from the original package that Diglib generated in order to direct the user to the content hosted on the Diglib server. The content from the package is not included in the package, but resides on the Diglib server. In other words, Diglib stores the original copy of the package, but uses the DiglibPackage to direct LMS' to the Diglib-hosted original package.

An LMS must, after downloading a package, parse the imsmanifest, and generate the tree structure from it. All the resource links point to a resource player in Diglib that handles security and license checks and launches a hosted player for the content on Diglib. One example of the resources part of the imsmanifest will look something like this:

<resource identifier="RES-xxxxxxxxxxxxxxxxxE4577DC8" type="webcontent" href="https://<Diglibserver>/ShowResource.ashx?Digliblinkid=<x>" />

Each time a link is clicked in the VLE, the VLE must use the SSO parameter program code (the same as logging a user on) and add these parameters to the link. This should happen when the user clicks, and not when the link is displayed on the web page, since the timestamp will time out after a while. The request the VLE then does will be something like:

https://<Diglibserver>/ShowResource.ashx?Digliblinkid=<x>&action=launch&[ssoParameters]

When adding the ssoParameters to the “show resource” links, the VLE must add the following parameter:

action, with values either “launch” or “display”.

“Launch” will launch the content, and “display” will redirect the user to the resource’s details page on Diglib.

In summary, the VLE only needs to implement a way to generate the SSO parameters once, and use this code both for sign-on mechanics, and also for adding parameters to the content links retrieved from the imsmanifest.xml file.

When launching content and a user is not signed in, Diglib will sign the user on with the ssoParameters supplied in the launch link.

Resource content that supports tracking are content that are somehow aware of its usage, that records its usage and that is able to communicate back to the LMS recorded data in some standardised format. Such formats are typically AICC/HACP and SCORM.

Diglib supports AICC/HACP tracking natively, i.e. it’s possible for a LMS to launch a resource with such tracking enabled.

In order to launch a resource with tracking enabled, the LMS must add the following parameters to the launchURL:

1. SID (string, max 255 characters)
2. ContextLaunchID (string, max 24 characters)
3. TrackbackURL (string)
4. UseTrackingStandard (string – use one of the specified tracking standards in supportedTrackingStandards)

The SID is a sessionId value that the LMS must generate uniquely for a user’s session.

ContextLaunchID is an ID that the LMS must generate uniquely for a user in a given context (for example the combination of the userId and the location where the package was downloaded to). The LMS needs to generate this ContextLaunchID identically the next time a user launches the resource from the same context. Diglib needs this identifier in order to keep track of the tracking session between user sessions in the LMS. An example of how this affects the user in practise is if the user has the same resource downloaded to two different courses. Tracking the user’s progress in the resource will then depend on the context that the user launches it from. In course X the user might not have started the resource yet, whereas in course Y, the user might have finished the resource.

The TrackbackURL is the URL where the LMS wants the tracking communication to be sent to. For example an AICC enabled content resource will send its PutParams command-request to this URL, and it is the LMS’ responsibility to handle it.

UseTrackingStandard specifies the tracking standard that the LMS wants to use. If empty, Diglib assumes the LMS wants to use “common” standard. The tracking standard must be one of the standards given in the “SupportedTrackingStandards” parameter that the LMS receives after requesting a resource.

Note that when playing content in Diglib with any tracking enabled, the LMS will not receive commands requesting previous state from the tracking communication, such as “GetParam” in AICC/HACP. The “GetParam” command will be sent to Diglib first, and Diglib will handle this command itself. Put commands, such as “PutParam” in AICC/HACP will be relayed to the LMS on the given TrackbackURL.

SCORM resources are a special case in Diglib. SCORM resources are played in a third party player from Icodeon, and it is not possible to track natively with SCORM (i.e.  to relay the requests directly back to the LMS). It is, however, possible to launch a tracking session for a SCORM package with the common standard. The common data is sent back to the LMS after each time the Icodeon player registers new data on a session. Diglib handles the conversion between the SCORM standard and the Diglib common standard.

Diglib common tracking is an effort to standardise the many different tracking standards into one common standard that VLEs integrating with Diglib may choose to implement and use.

Many LMS’ support the most widely used tracking standards today, i.e. SCORM and AICC/HACP. However, for LMSs that have not yet implemented this, Diglib can alleviate the implementation time and costs for supporting such tracking. New tracking standards are also emerging at the time of writing (one example being Common Cartridge), and Diglib tracking is an effort on part of Diglib to help LMSs support all tracking standards that Diglib support.

In a nutshell, if a LMS supports Diglib tracking standard, it will also support all tracking standards that Diglib supports. Forget all about thick standards documents! Also, if a new standard is introduced, the VLE will automatically support the standard by supporting the common Diglib tracking standard.

Launching content with Diglib tracking, the LMS either omits the UseTrackingStandard parameter, or sets it to “common” in the LaunchURL.

The Diglib tracking object is sent to the LMS as an XML formatted body of a POST operation to the “TrackbackURL” supplied.

The Diglib tracking object looks like this:

<?xml version="1.0" encoding="UTF-8"?>

<TrackingData>

    <SID>SESSION_93A20F80BDB2</SID>

    <Score>80</Score>

    <Status>Complete</Status>

    <TimeSpent>1800</TimeSpent>

    <Attempts>13</Attempts>

</TrackingData>

As you can see, the Diglib tracking object only consists of five nodes, namely Sid, Score, Timespent , Status, and Attempts.

Status is an enum that consists of the same values as the AICC standards:
Passed, Failed, Complete, Incomplete, NotAttempted, Browsed and Incomplete.

 In the model above, the communication involved in the tracking process is outlined.

1. Diglib receives a launch URL from the LMS with UseTrackingStandard=common
2. Diglib launches a tracking session with the content resource. “Native” tracking is then communicated between Diglib and the content. This is illustrated by the two way arrow between the Player and the Tracking service in the model.
3. For each tracking request from the content, Diglib saves it to an internal database.
4. After saving to the internal database, Diglib translates the native tracking to the Diglib common tracking standard, and sends it to the LMS as specified in this documentation.

Note that no state needs to be saved in the LMS between sessions, since Diglib handles this internally. The only thing the LMS needs to keep track of is the ContextLaunchID, since Diglib needs this to lookup a possible previous session and allow the tracking to continue from where the user left of last time. You may of course store the data, e.g. for reports in the LMS.