SCORM, xAPI o cmi5: qué contrato cubre cada estándar

«Tenemos ochocientos cursos SCORM y queremos migrarlos a xAPI». La frase parece una decisión tecnológica, pero todavía no lo es.

Puede significar que la organización quiere obtener datos más ricos, dejar de alojar contenido dentro del LMS, ejecutar actividades en una aplicación móvil, reutilizar cursos en varios campus o sustituir un reproductor antiguo. Cada objetivo exige un contrato distinto. Cambiar el botón de exportación de la herramienta de autor no resuelve por sí solo ninguno.

SCORM, xAPI y cmi5 suelen aparecer en la misma tabla porque los tres participan en ecosistemas de aprendizaje, aunque no ocupan la misma capa. SCORM define cómo empaquetar contenido, cómo lo lanza un LMS y cómo se comunican durante la ejecución, mientras xAPI se ocupa de describir y transportar evidencia de actividad hacia un LRS. Por su parte, cmi5 añade las reglas necesarias para que un LMS importe una estructura, lance unidades, gestione sesiones e interprete resultados mínimos de forma interoperable.

La comparación útil parte de esta pregunta: ¿qué sistema debe importar, lanzar, registrar, decidir la finalización y conservar la evidencia?

Si el problema combina empaquetado, lanzamiento y analítica, conviene escribir primero los tres contratos y asignarles una responsabilidad.

La decisión tiene tres capas

Separaría cualquier caso en tres preguntas:

1. Distribución. ¿Se entrega un paquete autocontenido, una estructura que referencia contenido remoto o una aplicación desplegada como producto?
2. Ejecución. ¿Quién autentica, lanza, crea la sesión, conserva el estado y decide finalización, éxito y puntuación?
3. Evidencia. ¿Qué hechos se registran, con qué vocabulario, en qué almacén y para qué decisiones posteriores?

Las tres tecnologías cubren esas capas de forma desigual:

Esta vista explica por qué «pasar de SCORM a xAPI» suele quedar incompleto. xAPI puede sustituir el canal de datos, pero no proporciona automáticamente el paquete, el reproductor, el lanzamiento ni las reglas de curso que antes aportaba SCORM. Si esas responsabilidades siguen siendo necesarias, hay que diseñarlas o adoptar un perfil como cmi5.

SCORM es un contrato de curso dentro del LMS

SCORM 2004 organiza su documentación en tres ámbitos. El Content Aggregation Model describe recursos, objetos compartibles, manifiesto, organización y empaquetado. El Run-Time Environment define el lanzamiento, la API que ofrece el LMS y el modelo de datos que intercambia el SCO. Sequencing and Navigation define cómo una estructura de actividades puede avanzar o ramificarse.

La imagen mental es un paquete que el LMS importa y aloja. Cuando abre un SCO, el contenido busca la API JavaScript del reproductor en la jerarquía de ventanas y comunica valores normalizados: inicialización, finalización, éxito, puntuación, tiempo, posición de reanudación, datos suspendidos e interacciones, según la versión y la implementación.

Esa restricción también es su fortaleza. Un proveedor puede entregar un ZIP que muchos LMS conocen, sin desplegar un servicio separado ni acordar una API de negocio. Para una biblioteca de cursos autocontenidos que necesita abrir, guardar avance y devolver un resultado sencillo, SCORM puede ser la opción de menor riesgo.

Lo elegiría cuando concurren estas condiciones:

• el contenido es web y puede vivir dentro del paquete o del reproductor;
• la institución necesita importarlo en varios LMS que soportan la misma versión;
• finalización, éxito, puntuación y reanudación cubren la decisión educativa;
• no hace falta consultar actividad normalizada desde otros sistemas;
• el contenido puede probarse como artefacto versionado y conservarse durante años.

No escribiría «SCORM compatible» sin versión. SCORM 1.2 y SCORM 2004 difieren en nombres, modelo de datos y capacidades; 2004 añade un modelo formal de secuenciación que no todos los productos implementan con la misma profundidad. La prueba debe fijar edición, perfil de empaquetado, comportamiento de la API y casos de reanudación.

Sus límites aparecen al salir de la sesión. El estándar no ofrece una interfaz común para exportar en bloque el historial del LMS. La comunicación depende, en la práctica, del navegador y de la relación entre contenido y ventana que expone la API. El vocabulario está acotado y la semántica detallada suele esconderse en suspend_data, interacciones o campos propios del autor. El paquete es portable, pero eso no garantiza que después puedan interpretarse todos sus datos.

SCORM conserva, por tanto, su utilidad dentro de un ámbito claro. Sustituir un contrato estable solo merece la pena si el nuevo sistema resuelve una necesidad que ese ámbito no cubre.

xAPI es un contrato de evidencia

xAPI describe experiencias mediante declaraciones. Una declaración incluye como mínimo actor, verbo y objeto; puede añadir resultado, el campo context, tiempo, autoridad y anexos. Un productor las envía a un Learning Record Store o LRS, que las valida, conserva y permite consultarlas.

La versión actual de la especificación es xAPI 2.0, normalizada como IEEE 9274.1.1-2023. Esa actualidad no elimina el trabajo de compatibilidad: hay productos y perfiles construidos sobre la familia 1.0.x. El contrato de una solución debe fijar qué versiones emite cada productor, cuáles acepta el LRS y cómo se transforman o conservan las declaraciones.

xAPI permite reunir evidencia de un simulador, una aplicación móvil, una práctica física, un recurso web o un LMS. También conserva declaraciones como hechos permanentes: si una deja de ser válida se anula mediante otra, no se edita silenciosamente. Esa propiedad favorece procedencia y análisis distribuido.

Ahora bien, xAPI no establece:

• cómo importa un LMS un curso;
• qué pantalla debe abrir ni quién la lanza;
• cómo obtiene una actividad sus credenciales en ese lanzamiento;
• dónde empieza y termina una sesión formativa;
• qué verbos equivalen a completar, superar o abandonar;
• qué sistema posee la calificación oficial;
• qué vocabulario debe compartir una organización.

Enviar actor completed course puede producir una declaración sintácticamente válida y una arquitectura semánticamente inútil. ¿Qué versión del curso? ¿Según qué criterio? ¿Quién tiene autoridad para afirmarlo? ¿Cómo se relaciona con la matrícula? ¿Puede otro productor usar el mismo verbo y objeto?

Por eso xAPI necesita perfiles, identificadores gobernados, plantillas de declaraciones y reglas de validación para un caso concreto. Si el objetivo es analítica del aprendizaje, el diseño continúa en la arquitectura que lleva del evento a la intervención. El LRS conserva declaraciones; la organización define qué significan y qué decisiones permiten.

Elegiría xAPI como contrato principal cuando la actividad atraviesa canales, no depende de un lanzamiento del LMS y la organización puede gobernar vocabulario, identidad, LRS, acceso, retención y consumo. No lo presentaría como formato de exportación de cursos.

cmi5 añade las reglas del curso que xAPI no trae

cmi5 es un perfil de xAPI para un caso preciso: una persona lanza contenido desde un LMS. Define una estructura de curso formada por Assignable Units o AU, que son unidades lanzables y gestionables. La estructura puede viajar como XML o dentro de un ZIP; las AU pueden alojarse en el paquete o referenciar direcciones externas.

En el lanzamiento, el LMS proporciona la dirección del LRS, el actor, el identificador de actividad, la matrícula y una dirección de un solo uso para obtener autorización. El LMS crea la sesión y la AU envía declaraciones con la matrícula, la sesión y la categoría exigidas. cmi5 fija declaraciones de inicio y terminación, reglas para finalización, superación, exención y abandono y criterios moveOn para decidir cuándo una AU satisface lo esperado.

Así combina dos cualidades que una implementación xAPI genérica no garantiza: el LMS conserva el control del curso y la evidencia viaja mediante un modelo consultable y extensible. El contenido puede residir en otro dominio. La edición Quartz define el lanzamiento mediante una URL en un contexto de navegador; una ejecución nativa o fuera del navegador necesita un mecanismo adicional no definido por esta edición y no debe darse por interoperable sin pruebas específicas.

cmi5 encaja cuando:

• el LMS debe importar una estructura y lanzar las actividades;
• el contenido remoto necesita actualizarse sin redistribuir todos los recursos;
• varias AU forman un curso con reglas comunes de finalización y superación;
• la institución quiere declaraciones xAPI adicionales sin perder una semántica mínima interoperable;
• LMS, LRS, herramienta de autor y contenido han probado el mismo perfil.

El último punto marca la frontera real. Que un LMS «tenga xAPI» no implica que importe, lance y evalúe cursos cmi5. Que una herramienta exporte cmi5 tampoco demuestra que el producto receptor implemente sesiones, estado, moveOn y acceso a datos como espera la organización. La lista pública de adopción del proyecto cmi5 declara productos, pero advierte que el grupo no los ha certificado ni avala su calidad. La organización solo debería aceptar la interoperabilidad después de probarla; el logotipo no basta.

También conviene fijar la versión. La especificación pública cmi5 Quartz referencia xAPI 1.0.x, mientras xAPI ha evolucionado a 2.0. No asumiría compatibilidad por proximidad de nombres: documentaría la matriz exacta entre AU, LMS y LRS y conservaría muestras de declaraciones aceptadas.

A veces la respuesta correcta es LTI

Un simulador externo necesita saber qué persona entra, desde qué curso, con qué rol; el docente debe seleccionarlo y la herramienta devolver una nota al libro del LMS. Esa necesidad no describe un paquete SCORM, una declaración xAPI ni necesariamente un curso cmi5. Describe una integración entre plataforma y herramienta.

LTI 1.3 puede cubrir el lanzamiento con identidad, curso y roles, además de los servicios académicos. Después, xAPI puede registrar la secuencia detallada del simulador en un LRS. No hay duplicación si cada contrato conserva una autoridad distinta: LTI se encarga de abrir y autorizar la actividad, mientras xAPI registra la evidencia. Explico esa separación en LTI, API o xAPI: tres fronteras, no tres rivales.

Tampoco usaría cmi5 para sincronizar matrículas, SCORM para una aplicación SaaS que cambia cada semana ni xAPI como orden de negocio para conceder una acreditación. El estándar no debe absorber procesos que pertenecen a otro dominio.

La matriz debe incluir operación y salida

La comparación habitual se queda en «datos simples» frente a «datos ricos». Una decisión que deba sobrevivir años necesita más dimensiones:

La última fila suele cambiar la decisión. Un producto puede ejecutar todos los formatos y seguir encerrando las declaraciones en un LRS sin exportación practicable, o aceptar paquetes mientras las fuentes permanecen en una herramienta propietaria. Para comprobar la portabilidad hay que ensayar la salida, no limitarse a una importación.

Migrar empieza por un inventario de comportamiento

En el inventario contaría las dependencias de cada curso, no solo el número de cursos. Para cada pieza registraría:

• versión de SCORM y resultado de la última prueba de conformidad;
• número de SCO, organización, secuenciación y navegación;
• uso real de finalización, éxito, puntuación, tiempo e interacciones;
• posición de reanudación y estructura de suspend_data;
• dependencia de ventanas emergentes, marcos, cookies, dominios o complementos;
• fuente editable, herramienta y versión con la que se publicó;
• requisitos de accesibilidad y evidencias de prueba;
• informes y procesos que consumen los datos actuales;
• propietario, vigencia, uso y fecha de retirada prevista.

Ese inventario separa el catálogo en cuatro grupos: se conservan los cursos estables cuyo contrato SCORM basta; se vuelven a publicar aquellos de los que existe la fuente y un formato objetivo verificable; se rediseñan las experiencias que necesitan otro modelo, como una simulación multicanal, y se retira el contenido sin uso, responsable o vigencia. Migrar todo por igual traslada deuda y encarece la plataforma nueva.

La accesibilidad también forma parte del contrato. Cambiar de SCORM a cmi5 no corrige por sí solo foco, teclado, subtítulos, contraste o reflujo. Las pruebas descritas en accesibilidad para plataformas de aprendizaje se aplican a la experiencia resultante, no a la sigla del paquete.

Una conversión no completa la migración

Si la herramienta de autor conserva el proyecto fuente y permite publicar de nuevo como cmi5, la conversión puede ser barata. Aun así hay que comparar comportamiento y datos. Un ajuste que antes escribía lesson_status puede convertirse en una combinación de declaraciones; el nuevo LMS puede interpretar moveOn de forma distinta; la reanudación puede cambiar de almacén.

Si solo queda el ZIP SCORM, la situación es otra. Extraer HTML y envolverlo con un emisor xAPI no recupera la intención pedagógica ni crea un perfil. Observar las llamadas a la API antigua y traducirlas solo proporciona una compatibilidad transitoria; no crea una arquitectura nueva. Puede ser útil como pasarela para conservar datos mientras se retira contenido, pero debe tener fecha de salida.

Definiría un contrato de equivalencia por curso:

La equivalencia no siempre significa identidad. Una migración puede mejorar el modelo y cambiar una regla, pero el cambio debe aparecer como decisión, no como efecto accidental del exportador.

La transición necesita dos sistemas de registro explícitos

Durante una migración convivirán paquetes SCORM y nuevas actividades. Intentar que todos escriban la misma tabla desde el primer día aumenta el riesgo. Mantendría el LMS como autoridad de matrícula y finalización oficial, y el LRS como autoridad de declaraciones. Una vista de reconciliación relaciona ambas sin fingir que son lo mismo.

Para cada resultado definiría:

• qué sistema lo origina;
• qué identificadores unen curso, versión, persona, matrícula y actividad;
• qué transformación lo convierte en estado oficial;
• qué ocurre si llega tarde, duplicado o fuera de orden;
• cómo se corrige en origen y en derivados;
• qué versión del contrato estaba vigente.

Un curso cmi5 puede producir la declaración de superación que el LMS usa para actualizar el expediente. Esa relación debe quedar registrada. Una declaración xAPI libre de un simulador puede ser evidencia para análisis sin cambiar la calificación. La autoridad procede del productor, el perfil y la relación registrada, no del verbo aislado.

Doce pruebas para un piloto serio

Antes de elegir formato para toda la biblioteca probaría un curso representativo y una actividad difícil:

1. importar y validar el paquete o estructura sin ajustes manuales;
2. lanzar con la identidad y matrícula esperadas;
3. cerrar de forma abrupta y reanudar en el estado correcto;
4. completar, superar, suspender y abandonar en casos separados;
5. comprobar puntuaciones mínimas, máximas, nulas y repetidas;
6. ejecutar dos sesiones y distinguirlas sin duplicar el resultado;
7. perder la red, recuperar y ordenar las declaraciones;
8. actualizar el contenido remoto o el paquete sin reescribir intentos pasados;
9. consultar y exportar evidencia con procedencia y versión;
10. corregir o anular un dato y propagar el cambio a informes;
11. ejecutar teclado, foco, reflujo, lector de pantalla y subtítulos;
12. retirar el proveedor y reconstruir curso, estado y evidencia en un entorno de ensayo.

El piloto debe incluir los LMS y LRS que realmente se usarán. Una prueba perfecta contra un reproductor de referencia demuestra conformidad básica; no demuestra que la combinación elegida tenga el mismo comportamiento, observabilidad, rendimiento o salida.

La decisión cabe en un registro de arquitectura

El resultado final debería poder escribirse así:

Situación. La organización distribuye cursos autocontenidos a quince clientes con LMS heterogéneos y solo necesita finalización, puntuación y reanudación.

Decisión. Mantener SCORM 1.2 para el catálogo existente probado y exigir fuente editable. Adoptar cmi5 para nuevas experiencias alojadas de forma centralizada solo en clientes cuya combinación LMS/LRS supere el piloto. Usar xAPI con un perfil propio para simuladores que no nacen en el LMS.

Consecuencias. Habrá dos runtimes durante la transición, una identidad que relacione matrícula y declaraciones, una vista de reconciliación y un plan de salida del reproductor antiguo. No se convertirán cursos sin fuente o sin uso; se retirarán.

Ese registro vale más que declarar «xAPI es el futuro». Hace visibles la compatibilidad, el coste operativo, la autoridad del dato y la condición que obligaría a revisar la decisión.

El contrato adecuado es el más pequeño que resuelve el problema

SCORM resuelve bien la distribución y la ejecución de un tipo concreto de curso; xAPI permite conservar evidencia distribuida sin depender del LMS, y cmi5 le añade las reglas necesarias para que un LMS gestione un curso lanzable. LTI cubre otra frontera cuando lo que se integra es una herramienta.

Ninguna organización tiene que recorrer una escalera de SCORM a xAPI y después a cmi5. Lo que debe hacer es repartir las responsabilidades entre el contrato más pequeño que cubra cada una, comprobar la combinación real de productos y preparar la salida antes de importar el primer curso.

Una migración mejora la plataforma cuando cambia una capacidad comprobable y conserva la trazabilidad de la decisión.