AICC-> SCORM

Si deve definire verso quale versione di SCORM si vogliono convertire i materiali AICC.

Se la versione è SCORM 1.2 le operazioni di conversione possono anche essere poche o nulle, a seconda del binding di partenza.

Se si parte da corsi che utilizzano il file binding l’operazione è complessa: si devono ‘smontare’ i corsi, individuare le singole chiamate che vengono fatte, trasformarle in chiamate alle API magari sviluppando un wrapper in ECMAscript per facilitarsi il compito di traduzione.

Se si parte da corsi che utilizzano l’HACP binding si può con opportuna ingegneria e qualche malizia da webmaster cercare un percorso più veloce trasformando le chiamate su HTTP in chiamate ad un wrapper che a sua volta le trasformi in chiamate API.

Se si parte da corsi che utilizzano l’API binding si è nel caso più fortunato, in quanto la modalità di funzionameno è la stessa di SCORM. Potrebbe non essere necessario alcun cambiamento, ma si deve comunque fare una verifica perchè potrebbero esserci chiamate con risposte in funzione della struttura del corso, diversamente definita da AICC e SCORM, che quindi potenzialmente potrebbero dover essere modificate.

Se la versione è SCORM 1.3 sono valide tutte le considerazioni precedenti per il come comunicare, ma devono essere riscritte tutte le chiamate perchè cambia il data model, passando da quello di AICC a quello di IEEE. Lo SCORM Run-Time Environment Data Model è basato su P1484.11.1 Draft Standard for Learning Technology - Data Model for Content Object Communication standard prodotto da IEEE LTSC Computer Managed Instruction (CMI).

La differenza non è abissale, ma le stesse chiamate indispensabili per comunicare l’inizio e la fine della fruizione sono chiamate con termini diversi, quindi vanno riscritte.

Andando nel dettaglio ci sono chiamate presenti nell’uno e non nell’altro modello, quindi non è sufficiente sviluppare un ‘traduttore’ di chiamate.