SCORM 1.2 vs SCORM 2004 vs xAPI vs cmi5: ¿qué estándar usar?
SCORM 1.2, SCORM 2004, xAPI y cmi5 son cuatro estándares de e-learning distintos con capacidades, requisitos de LMS y casos de uso diferentes. Esta guía explica cada estándar con claridad y ofrece un marco de decisión para elegir el correcto.
Todo proyecto de e-learning llega tarde o temprano a la misma pregunta: ¿en qué formato exportamos? SCORM 1.2, SCORM 2004, xAPI y cmi5 no son intercambiables. Representan generaciones distintas de pensamiento sobre cómo se comunican los sistemas de aprendizaje, y elegir el equivocado implica un seguimiento roto en el LMS o una infraestructura sin aprovechar.
Este artículo explica cada estándar, cómo funciona y cuándo es la elección correcta.
SCORM 1.2 (1999)
SCORM 1.2 es la especificación de e-learning más antigua y ampliamente soportada. Desarrollada por ADL (Advanced Distributed Learning) y publicada en 1999, define cómo un paquete de curso se comunica con un LMS mediante llamadas a la API de JavaScript en un objeto de ventana de navegador compartido.
Cómo funciona: El LMS expone un objeto JavaScript (API) en el navegador. El curso lo localiza y llama a funciones como LMSInitialize, LMSSetValue y LMSCommit para reportar el progreso, las puntuaciones y el estado de finalización.
Capacidades principales:
- Estado de finalización:
passed,failed,completed,incomplete,not attempted,browsed - Una sola puntuación (cmi.core.score.raw)
- Datos de suspensión: una cadena de hasta 4.096 caracteres para guardar el estado del alumno
- Seguimiento del tiempo (cmi.core.total_time)
Limitaciones:
- En la práctica, un solo SCO (Shareable Content Object) por paquete; la secuenciación multi-SCO es teóricamente posible pero raramente implementada correctamente por los LMS
- Sin seguimiento por objetivo
- El límite de 4.096 caracteres en los datos de suspensión puede ser insuficiente para cursos adaptativos complejos
- Sin soporte para uso sin conexión ni dispositivos móviles
SCORM 1.2 sigue siendo el estándar dominante por su compatibilidad universal con los LMS. Según el análisis xAPI vs. SCORM de iSpring, SCORM 1.2 continúa siendo el formato más utilizado en las plataformas de aprendizaje corporativas.
Elegir SCORM 1.2 cuando: el LMS es antiguo o su compatibilidad es desconocida, la prioridad es la compatibilidad garantizada y el aprobado/suspenso con una sola puntuación es suficiente.
SCORM 2004 (2001–2009)
SCORM 2004 se publicó en cuatro ediciones entre 2001 y 2009. Corregía las limitaciones de SCORM 1.2 con un modelo de datos más rico, lógica de secuenciación real y seguimiento por objetivo.
Mejoras clave sobre SCORM 1.2:
- Secuenciación y navegación: reglas de ramificación entre SCOs basadas en el rendimiento del alumno
- El estado de finalización y el estado de éxito son campos de datos separados
- Puntuaciones por objetivo y seguimiento del dominio
- Seguimiento de interacciones (cmi.interactions) para informes detallados de cuestionarios
- Mayor capacidad de datos de suspensión
Limitaciones:
- Las implementaciones en LMS son inconsistentes. Muchos LMS declaran soporte para SCORM 2004 pero solo implementan parcialmente el motor de secuenciación.
- Más complejo de crear y probar correctamente.
- Sigue siendo basado en JavaScript del navegador, por lo que el seguimiento sin conexión y en móvil siguen siendo imposibles.
Elegir SCORM 2004 cuando: el LMS lo implementa correctamente (verificarlo antes de comprometerse), se necesita secuenciación multi-módulo o informes por objetivo, y se publica en un LMS corporativo moderno como SAP SuccessFactors o Cornerstone.
xAPI / Tin Can API (2013)
xAPI (también conocido como Tin Can API o Experience API) fue desarrollado como una reimaginación completa de cómo se pueden capturar los datos de aprendizaje. Publicado en 2013, trasladó la comunicación fuera del modelo de JavaScript del navegador. Como explica xAPI.com, el concepto central es simple: las actividades de aprendizaje generan declaraciones con la forma "Actor realizó Verbo sobre Objeto."
Cómo funciona: En lugar de comunicarse mediante JavaScript del navegador, xAPI envía solicitudes HTTP POST a un Almacén de Registros de Aprendizaje (LRS). El LRS es una base de datos que almacena y sirve declaraciones xAPI. El LMS ya no es necesario como intermediario.
Capacidades principales:
- Registrar cualquier actividad de aprendizaje: cursos formales, vídeos vistos, simulaciones, tareas en el trabajo, interacciones en aplicaciones móviles
- Seguimiento sin conexión: las declaraciones se guardan localmente y se sincronizan al recuperar la conectividad
- El aprendizaje fuera de un LMS tradicional puede capturarse
- Vocabulario de declaraciones rico: cualquier verbo, cualquier tipo de actividad
Infraestructura necesaria: Se requiere un LRS. Como describe la guía de LRS de xAPI.com, el LRS es un sistema independiente del LMS. Algunos LMS incluyen un LRS integrado; otros requieren un producto independiente.
Elegir xAPI cuando: se necesita registrar el aprendizaje fuera del LMS (aplicaciones móviles, simulaciones, eventos presenciales), se dispone de un LRS o se planea construirlo, o se necesitan análisis detallados de declaraciones más allá del aprobado/suspenso.
cmi5 (2016)
cmi5 es un perfil construido sobre xAPI que restaura el modelo de lanzamiento y autenticación del LMS que xAPI eliminó intencionalmente. Publicado por ADL en 2016, combina la flexibilidad de xAPI con el modelo estructurado de integración con LMS que necesitan los departamentos de formación empresarial. La página de cmi5 de Rustici Software y la explicación de cmi5 de Easygenerator lo describen como "SCORM bien hecho con xAPI."
Lo que cmi5 añade sobre xAPI puro:
- Mecanismo de lanzamiento definido: el LMS lanza contenido cmi5 igual que lanza SCORM
- Declaraciones obligatorias:
launched,initialized,terminated,passed,failed,completedson requeridas, lo que proporciona datos consistentes al LMS - Autenticación: el endpoint del LRS y las credenciales se pasan al contenido en el momento del lanzamiento, no están codificados de forma fija
- Lógica de avance: el LMS controla cuándo el alumno puede pasar a la siguiente actividad
Elegir cmi5 cuando: se quiere la riqueza de datos de xAPI con el modelo de integración del LMS de SCORM, el LMS lo soporta (SAP SuccessFactors y Cornerstone lo hacen), y se construye una biblioteca de contenido a largo plazo que debe ser a prueba de futuro. Como señala la descripción general de cmi5 de xAPI.com, cmi5 es cada vez más el estándar recomendado para el contenido empresarial nuevo.
Tabla comparativa
| SCORM 1.2 | SCORM 2004 | xAPI | cmi5 | |
|---|---|---|---|---|
| Año de publicación | 1999 | 2001–2009 | 2013 | 2016 |
| LMS requerido | Sí | Sí | No | Sí (solo lanzamiento) |
| LRS requerido | No | No | Sí | Sí |
| Soporte sin conexión | No | No | Sí | Sí |
| Seguimiento por objetivo | No | Sí | Sí | Sí |
| Secuenciación/ramificación | Limitada | Completa | Personalizada | Definida |
| Compatibilidad con LMS | Universal | Variable | Vía LRS | En crecimiento |
Marco de decisión
- LMS antiguo o compatibilidad desconocida: SCORM 1.2.
- LMS corporativo moderno, con necesidad de secuenciación y seguimiento por objetivo: SCORM 2004 (verificar soporte del LMS primero).
- Aprendizaje fuera del LMS, móvil, sin conexión o seguimiento de simulaciones: xAPI.
- LMS empresarial y estrategia de contenido a prueba de futuro: cmi5.
¿No está seguro de qué estándar usa un paquete existente? Un validador SCORM gratuito detecta el estándar — SCORM 1.2, SCORM 2004, xAPI o cmi5 — a partir del descriptor del paquete y comprueba su estructura en segundos, directamente en el navegador.
El lugar de Skillsail
Skillsail exporta los cuatro formatos: SCORM 1.2, SCORM 2004, xAPI y cmi5, además de HTML5 autónomo. Esto significa que se elige el estándar que mejor se adapta al LMS y los requisitos de informes sin estar vinculado a un único formato de salida. En despliegues multilingües, cada variante de idioma se exporta como un paquete separado en el formato seleccionado.