Guide MOOC – Partie 2 – API MOOC, le SCORM 1.2

Winoows 10 banner

Dans notre précédent article, nous vous présentions quelques éditeurs permettant de concevoir et de packager un cours Mooc. Un point important est à prendre en compte dans cette étape, l’API / standard utilisé pour le package final. Si le format SCORM semble un incontournable, il se décline en de nombreuses versions et sous-versions, et n’est plus un standard en devenir comme pourrait l’être TinCan.

Dans cet article nous proposons un article centré sur l’API SCORM, avec un rappel des différents niveaux d’API et les requis pour se mettre en conformité avec sa sous-version la plus utilisée : SCORM 1.2.

Pourquoi le SCORM ?

Comme nous l’apprend la page Wikipedia dédiée, le SCORM ou Sharable Content Object Reference Model est un standard développé principalement par l’agence américaine ADL (Advanced distributed learning) en vue de respecter les exigences suivantes : Accessibilité, adaptabilité, durabilité, interopérabilité et réusabilité. Pour simplifier, la définition d’un standard de package autonome, respectant les contraintes d’accessibilité numérique modernes et, à travers une API standard, compatible avec les plateformes d’édition et de présentation (LMS).

Pour résumer : SCORM 1.0 : draft du standard SCORM 1.1 : première implémentation SCORM 1.2 : première version adoptée massivement et ayant fait connaître le format SCORM. C’est toujours aujourd’hui un des formats les plus utilisés, y compris par les industriels du Mooc. SCORM 2004 “1st Edition” : ni publiée ni utilisable SCORM 2004 “2nd Edition” : réponse rapide d’ADL aux problèmes de la première édition SCORM 2004 “3rd Edition” : sous-version la plus utilisée parmi les versions 2004

Aujourd’hui c’est la version 1.2 qui est la plus utilisée parmi toutes ces éditions du standard SCORM.

Concrètement, le SCORM v1.2 est composé de deux parties : L’environnement d’exécution (Run-Time Environment) définit comment le contenu devrait se comporter une fois qu’il a été exécuté dans le LMS. Le modèle d’agrégation de données (Content Aggregation Model) définit comment vous devriez packager votre contenu de sorte à ce qu’il puisse être importé dans un LMS. Ceci implique la création de fichiers XML qu’un LMS peut lire pour détecter la configuration nécessaire à la présentation de votre contenu.

L’environnement d’exécution (Run-Time Environment)

Requis pour implémenter un connecteur d’API. Le connecteur d’API doit se présenter sous la forme d’un object ECMAScript (Javascript) nommé “API” xqui est accessible à travers le DOM. L’adaptateur doit implémenter les 8 fonctions suivantes :

LMSInitialize() LMSFinish() LMSGetValue() LMSSetValue() LMSCommit() LMSGetLastError() LMSGetErrorString() LMSGetDiagnostic()

Pour un niveau minimal de conformité SCORM, la seule chose dont un morceau de contenu a besoin est d’appeler LMSInitialize() quand il démarre et ensuite appeler LMSFinish() quand il en sort. C’est possiblement aussi simple, dans les cas d’usage réels cependant, les utilisateurs souhaitent une interaction beaucoup plus riche.

Le modèle d’agrégation de données (Content Aggregation Model)

Il se divise en trois parties : Package du contenu (Content Packaging) Modèle de contenu (Content Model) Méta-données (Meta-data)

La spécification du package de contenu (Content Packaging) définit comment le modèle de contenu (Content Model) et les méta-données (Meta-data) sont implémentées. Elle requiert tout le contenu à transférer dans un dossier ou un fichier ZIP appelé un PIF. À la racine de ce dossier doit se trouver un fichier XML appelé “imsmanifest.xml” contenant les informations de spécification du modèle de contenu et des méta-données dans un format bien définit.

Le modèle de contenu définit un puissant modèle pour distinguer le contenu en des unités réutilisables de taille arbitraire. Ces unités sont appelées Objets de Contenu Partageables (Sharable Content Objects ou SCO) et “Assets”. Un “asset” est simplement une “représentation électronique d’un média, texte, images, sons, pages web, ou tout autre format de données”. Par exemple, les “assets” incluent des photos, des extraits vidéo ou audio, etc… Un SCO est donc une collection d’“assets” représentant une unité logique d’apprentissage.

La spécification de méta-données procure un mécanisme pour décrire le contenu utilisant un vocabulaire commun pré-défini. Ce vocabulaire a 9 catégories, générale, cycle de vie, meta- metadata, technique, éducation, droits, relation, annotation, et classification. La spécification des méta-données indique un modèle de données très riche. Cependant, seule un sous jeu d’éléments de données sont requis pour atteindre la conformité SCORM.

L’exemple d’un fichier “imsmanifest.xml”

   
<?xml version="1.0" standalone="no" ?>
<!--
Single SCO content packaging example. SCORM 1.2.

Provided by Rustici Software - http://www.scorm.com

This example demonstrates the simplest possible manifest, containing just one SCO and
no metdata or sequencing information.
-->

<!--
The manifest node contains a unique identifer for this course and the course's version number.
The schema declartions are important to ensure you are delivering valid XML. For the most part
these should remain static. Other schema prefixes are allowed, but can limit interoperabilty.

The XSD files for SCORM 1.2 are not strictly valid and may cause errors in some XML validators.
-->
<manifest identifier="com.scorm.golfsamples.contentpackaging.singlesco.12" version="1"
         xmlns="http://www.imsproject.org/xsd/imscp_rootv1p1p2"
         xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_rootv1p2"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.imsproject.org/xsd/imscp_rootv1p1p2 imscp_rootv1p1p2.xsd
                             http://www.imsglobal.org/xsd/imsmd_rootv1p2p1 imsmd_rootv1p2p1.xsd
                             http://www.adlnet.org/xsd/adlcp_rootv1p2 adlcp_rootv1p2.xsd">

  <!--
  The metadata node simply declares which SCORM version this course operates under.
  In SCORM 1.2 there isn't a controlled vocabulary for schemaversion, it can be any value
  but a descriptive value is preferred.
  -->
  <metadata>
    <schema>ADL SCORM</schema>
    <schemaversion>1.2</schemaversion>
  </metadata>
  <!-- There is just one organization. The organization contains just one item.-->
  <organizations default="golf_sample_default_org">
    <organization identifier="golf_sample_default_org">
      
      <item identifier="item_1" identifierref="resource_1">
        
      </item>
    </organization>
  </organizations>
  <!--
  There is just one resource that represents the single SCO that comprises the entirety of this course.
  The href attribute points to the launch URL for the course and all of the files required by the course
  are listed.

  One subtle difference between SCORM 1.2 and SCORM 2004 is the cast of the letter "t" in the
  adlcp:scormtype attribute
  -->
  <resources>
    <resource identifier="resource_1" type="webcontent" adlcp:scormtype="sco" href="shared/launchpage.html">
      <file href="Etiquette/Course.html"/>
      <file href="Etiquette/course.jpg"/>
      <file href="Etiquette/Distracting.html"/>
      <file href="Etiquette/distracting.jpg"/>
      <file href="Etiquette/Play.html"/>
      <file href="Etiquette/play.jpg"/>
      <file href="Etiquette/questions.js"/>
      <file href="shared/assessmenttemplate.html"/>
      <file href="shared/background.jpg"/>
      <file href="shared/cclicense.png"/>
      <file href="shared/contentfunctions.js"/>
      <file href="shared/launchpage.html"/>
      <file href="shared/scormfunctions.js"/>
      <file href="shared/style.css"/>
    </resource>
  </resources>
</manifest>

Si le SCORM 1.2 semble le standard incontournable du packaging de cours MOOC, il faut prendre en compte deux axes de pondération : 1. votre capacité à packager votre contenu dans une archive, ce qui peut-être limitant si vous comptez par exemple faire appel à un webservice pour dynamiser le contenu de vos slides de cours, 2. la compatibilité avec le LMS distant, les plateformes de présentation MOOC celles-ci ne supportant pas toutes les APIs voire proposent des hybridations propriétaires.

Pour ces deux points, rendez-vous pour les parties « 3 – MOOC APis, suite et fin » et « 4 – LMS et support API » de notre guide MOOC.

Sources : - ADL SCORM http://www.adlnet.org/scorm.html - SCORM 1.2 Overview for developers : http://scorm.com/scorm-explained/technical-scorm/scorm-12-overview-for-developers/ - SCORM 1.2 Specification – zip http://www.adlnet.org/wp-content/uploads/2011/07/SCORM_1_2_pdf.zip - SCORM 1.2 Test Suite Readme http://www.adlnet.org/wp-content/uploads/2011/07/SCORM1_2_TestSuite1_2_7ST_ReadMe.htm