We are pleased to announce the release of SCORM Driver version 6.0! SCORM Driver 6.0 introduces some changes to interaction identifier generation that significantly improve the usability of Driver for internationalized courses in SCORM 2004 and xAPI.
What actually changed, in summary?
Previously, functions that called for an identifier (e.g., SD.CreateResponseIdentifier) would replace all problematic characters with underscores. For example, "¡la niña!" would be transformed into "_la_ni_a_". This presented problems for some vendors of non-English content.
Now, in SCORM 2004 only, the identifiers will be turned into percent-encoded URNs: "¡la niña!" will be transformed into "urn:scormdriver:%C2%A1la%20ni%C3%B1a!". In xAPI, the identifiers will be transformed into percent-encoded IRIs: "¡la niña!" will be transformed into "urn:scormdriver:¡la%20niña!". This change may necessitate changes in the software that was reporting on SCORM Driver courses, depending on how SCORM Driver was used.
The behavior of SCORM 1.2 and AICC will be unaffected.
What is an interaction identifier and why is this important?
When reporting on a learner's course experience, sometimes it is necessary to report at a lower level of detail than the high-level score or success status. One might wonder how learners performed on an individual multiple-choice question, for example. To make this possible, it is necessary to give the multiple-choice question ("interaction") a name ("identifier") so that it can be referenced later. The SCORM standards specify various restrictions about what constitutes a valid interaction identifier: notably, various punctuation characters, whitespace characters, unprintable characters, and characters outside the ASCII character set are not allowed. SCORM Driver enforced this requirement by replacing invalid characters with underscore characters: if the content provided Driver with an identifier of "la niña", Driver would change the identifier to "la_ni_a".
At the same time, SCORM does not provide a way to report on the text of a question; as a workaround, many content vendors started using the text of a question as the identifier for the interaction so they could view that text later from their reporting system. This presents a problem for vendors of internationalized content: international characters are not allowed. To illustrate, consider this question about Homer's Iliad: "Fill in the blank: μῆνιν ἄειδε ___ Πηληϊάδεω Ἀχιλῆος οὐλομένην".* SCORM Driver would transform the text into "Fill_in_the_blank:____________________________________________", which defeats the point of using the identifier as question text!
Fortunately, the SCORM 2004 standards suggest a workaround. Unlike earlier versions of SCORM, SCORM 2004 recommends that identifiers should actually be URIs, and if possible, URNs. A URI ("Uniform Resource Identifier") is a string of characters in a particular format that identifies something. The URIs we use most often are called URLs ("Uniform Resource Locator"), such as "http://scorm.com" or "ftp://scorm.com". URNs ("Uniform resource names") are URIs that persistently name something (unlike URLs, which can change), and they generally look like "doi:10.10.1038/nphys1170" (identifying an article in an academic journal) or "urn:isbn:0451450523" (identifying a book by its ISBN number).
One advantage of using URIs is that URIs have a well-defined method of encoding problematic characters called percent encoding. Percent-encoding takes these characters and replaces them by one or more units of a percent sign ("%") followed by two hexadecimal digits. For example, "http://example.com/to_be_or_not_to_be?.jpg", when properly encoded, would transform to "http://example.com/to_be_or_not_to_be%3F.jpg".
We decided to have Driver transform all user-provided identifiers that were not already URIs into URNs; we do this by prepending the customer provided identifier text with "urn:scormdriver:", and then URI-encoding the latter half. So, the problematic question text above ("Fill in the blank: μῆνιν ἄειδε ___ Πηληϊάδεω Ἀχιλῆος οὐλομένην") would now be transformed into "Fill%20in%20the%20blank%3A%20%CE%BC%E1%BF%86%CE%BD%CE%B9%CE%BD%20%E1%BC%84%CE%B5%CE%B9%CE%B4%CE%B5%20___%20%CE%A0%CE%B7%CE%BB%CE%B7%CF%8A%CE%AC%CE%B4%CE%B5%CF%89%20%E1%BC%88%CF%87%CE%B9%CE%BB%E1%BF%86%CE%BF%CF%82%20%CE%BF%E1%BD%90%CE%BB%CE%BF%CE%BC%CE%AD%CE%BD%CE%B7%CE%BD". While the end result is clearly difficult for humans to read, nearly all programming languages provide simple support for decoding URI-encoded data, and so this approach has the advantage of not losing any information.
What about xAPI?
A similar change was made for xAPI. However, xAPI was built from the start with internationalization in mind, and so xAPI uses IRIs ("Internationalized Resource Identifiers") instead of URIs. The difference between IRIs and URIs is that IRIs accept internationalized characters, while URIs do not. Whitespace and certain punctuation characters will still be encoded.
Considering our example question once again ("Fill in the blank: μῆνιν ἄειδε ___ Πηληϊάδεω Ἀχιλῆος οὐλομένην"), the interaction identifier generated for xAPI content would be "Fill%20in%20the%20blank%3A%20μῆνιν%20ἄειδε%20___%20Πηληϊάδεω%20Ἀχιλῆος%20οὐλομένην". The result is slightly easier to read, but still can be easily decoded by the URI-decoding libraries of most programming languages.
Does this affect SCORM 1.2 or AICC?
No, this change does not affect SCORM 1.2 or AICC. In the future, we may provide a similar work around for these learning standards. Because SCORM 2004 recommends using URIs as identifiers, this suggests a natural method for encoding internationalized characters (URI encoding, or "percent encoding"). Since SCORM 1.2 and AICC do not make this recommendation, it is in no way clear that percent encoding would in fact yield valid SCORM 1.2 or AICC identifiers.