Determination of SCORM version

1 Summary

When importing a SCORM package, ILIAS automatically determines whether the package uses SCORM 1.2 or SCORM 2004 by analysing its imsmanifest.xml. The current manual selection of the SCORM version is removed, preventing new SCORM 1.2 packages from being imported as SCORM 2004 packages and processed by the SCORM 1.2 emulation and conversion mechanism. Existing learning modules that have already been converted and use this mechanism remain functional.

2 Problem Statement

When creating a SCORM learning module, users currently have to select either “SCORM 1.2” or “SCORM 2004 3rd/4th Edition” before uploading the package.

This selection requires technical knowledge about the uploaded package. The relevant information is not necessarily visible in the file name or otherwise known to the person importing the package. Users may therefore select a version that does not correspond to the package’s imsmanifest.xml.

The selected version determines which ILIAS SCORM implementation and object subtype is used. An incorrect selection can result in an incorrectly created learning module, import errors, runtime errors or incorrect tracking behaviour.

In addition, the SCORM 2004 implementation still contains a mechanism that attempts to convert a package not recognised as SCORM 2004 into SCORM 2004. The mechanism transforms the package manifest and adds a generic runtime wrapper that maps SCORM 1.2 API calls to the SCORM 2004 runtime environment.

This means that selecting “SCORM 2004” for a SCORM 1.2 package can currently result in the package being automatically converted and executed by the SCORM 2004 player instead of being rejected or imported as a native SCORM 1.2 learning module.

This behaviour is problematic because:

The Feature Wiki request Abandon SCORM 1.2-Emulation was accepted for ILIAS 5.2 and is documented as implemented. However, the conversion and wrapper mechanism is still present and can still be triggered by importing a SCORM 1.2 package as a SCORM 2004 object.

The SCORM version is already described by version-specific information inside the package manifest. Requiring users to provide the same information manually is therefore unnecessary and introduces an avoidable source of error.

3 Concept

ILIAS determines the SCORM version automatically during the import of a raw SCORM package.

The version is determined after the package has been uploaded but before a repository object is created. ILIAS opens the ZIP archive, locates the imsmanifest.xml in the root directory of the package and parses the manifest.

The detection uses version-specific information contained in the manifest, in particular:

The exact spelling of the schema version may differ between valid packages. Detection must therefore not depend on a single literal string. Instead, ILIAS evaluates the available version-specific information consistently.

A package is assigned to a version if the manifest contains at least one unambiguous version-specific indicator and no conflicting indicator.

Based on the detected version, ILIAS creates the appropriate object subtype:

No manual version selection or configuration option is provided. A manual override would allow users to create the same mismatch that this feature is intended to prevent.

3.1 Prevention of new SCORM 1.2 emulation

A package detected as SCORM 1.2 must never be passed to the SCORM 2004 import implementation.

In particular, the import MUST NOT:

The existing conversion mechanism must no longer be reachable through the regular import of a raw SCORM package.

Version detection must be based on positive identification. A package must not be treated as SCORM 1.2 merely because its schema version is not one of a small number of recognised SCORM 2004 strings. Likewise, a package must not be treated as SCORM 2004 merely because the user selected this version.

3.1.1 Existing emulated learning modules

Existing learning modules that were previously imported as SCORM 2004 objects and converted by the SCORM 1.2 emulation mechanism must remain functional.

The feature DOES NOT retroactively:

Existing converted packages may contain a transformed SCORM 2004 manifest, a backup of the original manifest and copied runtime wrapper files. These files must not be deleted or modified by an update.

The runtime functionality required for these existing objects must remain available. Code used exclusively to perform new conversions may be disabled or removed only if this does not affect the execution, copying, export or re-import of existing converted objects.

Automatic version detection must not be applied retrospectively when an existing learning module is opened, started or updated to a newer ILIAS version.

3.2 Copy and ILIAS export/import

Copies of existing emulated learning modules must remain functional.

ILIAS export files containing an existing emulated learning module are not considered raw SCORM packages. Their existing object subtype and already converted package data are retained when the ILIAS export file is imported.

Importing such an ILIAS export must not perform the SCORM 1.2-to-2004 conversion again.

3.3 Uploading new package versions

The version of a newly uploaded raw SCORM package must match the subtype of the existing learning module:

An unconverted SCORM 1.2 package must not be newly converted when it is uploaded to an existing SCORM 2004 object, including an existing object that originated from the former emulation mechanism.

Such an upload is rejected with an explanatory message. The content and tracking data already stored in the existing object remain unchanged.

Proposed message:

The uploaded package uses SCORM 1.2, but this learning module uses the SCORM 2004 runtime environment. Automatic conversion of SCORM 1.2 packages to SCORM 2004 is no longer supported. Please create a new SCORM 1.2 learning module.

This restriction is necessary to ensure that the emulation is not used for new package content while preserving the operability of already converted content.

3.4 Error handling

ILIAS must not guess or silently fall back to a default version.

The import is rejected if:

No repository object is created and no incomplete SCORM data remains in the repository.

ILIAS displays an error message explaining that the SCORM version could not be determined from the manifest. The message should advise the user to validate, correct or re-export the package.

Proposed message:

The SCORM version could not be determined from the imsmanifest.xml. The manifest contains missing, unsupported or conflicting version information. Please validate the SCORM package and upload a corrected or newly exported package.

Where possible, a more specific message should be presented, for example:

The imsmanifest.xml contains conflicting indicators for SCORM 1.2 and SCORM 2004.

Technical details may additionally be written to the SCORM component log.

3.5 Successful import

After successful detection, the package is imported using the existing native import process for the detected SCORM version.

The confirmation message should state the detected version, for example:

The SCORM package was imported as SCORM 1.2.

or:

The SCORM package was imported as SCORM 2004.

The automatically determined version corresponds to the existing SCORM object subtype and cannot be changed after the object has been created.

3.6 Scope

Automatic version detection applies to the initial creation of a learning module from a raw SCORM ZIP package, regardless of whether the package is selected from the local device or from an upload directory.

The same detection service must be used by every ILIAS core entry point that imports or replaces a raw SCORM package. It must not be possible to bypass detection through another core import path.

The following processes retain their existing object identity:

3.7 Compatibility

No existing SCORM object or stored tracking data is migrated.

Users familiar with the existing import form will notice that the manual “Type” selection is no longer available. Apart from this simplification, the established import workflow remains unchanged.

Packages with a valid and unambiguous manifest can be imported without additional interaction. Packages that could previously be imported by selecting SCORM 2004 and relying on the automatic SCORM 1.2 conversion are imported as native SCORM 1.2 objects instead.

Packages containing missing, unsupported or contradictory version information are rejected. They must be corrected or re-exported by the authoring system.

This approach implements the intention of the accepted request “Abandon SCORM 1.2-Emulation” for new package imports without breaking existing converted learning modules.

No additional third-party software or external service is required.

4 User Interface Modifications

4.1 List of Affected Views

The exact breadcrumb of the second view may depend on the final placement of the existing upload function.

4.2 User Interface Details

4.2.1 Import SCORM Package

The existing radio group “Type” with the following options is removed:

The existing file selection remains available:

No replacement input for the SCORM version is introduced.

When the user selects “Create”, ILIAS uploads the package and determines its SCORM version on the server. No additional confirmation step is required.

After a successful import, ILIAS redirects the user to the created learning module and displays the detected SCORM version in the confirmation message.

If detection fails, the user remains in the import workflow and receives an actionable failure message. No repository object is created.

4.2.2 Upload New Version

The version of the uploaded package is determined automatically.

If it does not match the native subtype of the existing learning module, the upload is rejected. In particular, a SCORM 1.2 package is not converted for use in a SCORM 2004 object.

The existing content and tracking data remain unchanged after a rejected upload.

4.3 New User Interface Concepts

No new user interface concept is introduced.

The proposal removes an existing radio group and uses existing ILIAS UI components for:

4.4 Technical Aspects

Version detection must take place before the SCORM object subtype is instantiated and before the repository object is created.

The detection should be implemented as a dedicated service within the SCORM components. The service should receive the uploaded package or manifest and return one of the following results:

XML processing must be namespace-aware. It must not rely exclusively on element prefixes because XML prefixes can be chosen freely by package authors. Namespace URIs and manifest values have to be evaluated instead.

The current SCORM 2004 import implementation invokes a conversion method for manifests that are not recognised as one of a limited number of SCORM 2004 schema versions. This implicit fallback must no longer be used for newly uploaded raw SCORM packages.

The implementation must clearly separate:

The detection result must control the object subtype before package-specific import logic is executed.

For new SCORM 1.2 imports, the SCORM 2004 conversion method and the XSL transformation used to convert SCORM 1.2 manifests must not be invoked. The generic runtime wrapper must not be copied into the package.

The implementation must identify which parts of the existing emulation code are required only during conversion and which parts are still required to execute existing converted packages. Runtime dependencies required by existing objects must be retained.

No database schema change is expected. If reliable identification of legacy emulated objects requires an explicit persistent marker, such a marker may be introduced. Existing converted objects would then have to be identified safely during migration. However, the preferred solution is to preserve them without requiring a data migration.

The manifest should be read directly from the ZIP archive before the complete archive is extracted.

5 Non-Functional Implications

5.1 Security

The feature does not introduce a new endpoint, permission or externally accessible interface.

It processes an XML file supplied as part of an existing upload process. XML parsing must be performed with external entities and external network access disabled to prevent XML External Entity attacks and unintended retrieval of external resources.

The implementation should reuse the existing secure archive and XML processing facilities of ILIAS. Existing protection against oversized uploads, unsafe archive entries, path traversal and excessive extraction must remain effective. The size of the manifest processed for detection should be limited appropriately.

Disabling the automatic transformation of newly uploaded SCORM 1.2 packages reduces the amount of package modification performed during import. It also prevents wrapper code from being added automatically to newly uploaded packages.

No separate security concept is considered necessary because the feature does not introduce a new attack surface beyond the existing SCORM upload.

5.2 Privacy

The feature does not require the storage or processing of additional personal data.

The automatically determined SCORM version is technical package metadata and is not personal data.

Existing personal data and tracking data of SCORM learning modules are not changed. In particular, existing tracking data of previously emulated learning modules is neither migrated nor deleted.

5.3 Accessibility Implications

No new accessibility issue is introduced.

Removing the manual radio group simplifies the form and reduces the number of required interactions. Success and failure information must be presented using the existing accessible ILIAS message components and must not rely on colour alone.

Error messages must clearly describe the problem and provide an appropriate corrective action.

6 Process Information

6.1 Involved Authorities

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Wischniak, Stanislav [wischniak]

6.3 Funding

7 Discussion

8 Implementation

Feature has been implemented by {Please add related profile link of this person}

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

8.4 Approval

Approved at {date} by {user}.