OJS 3.6 XML JATS SciELO: ¿sirve para SciELO o Redalyc?

OJS 3.6 XML JATS SciELO: ¿sirve para SciELO o Redalyc?

OJS 3.6 XML JATS SciELO es una combinación que ya despierta expectativas legítimas. PKP anunció que su próxima versión podrá producir HTML, PDF y XML JATS desde HTML estructurado. Eso puede simplificar una parte del cierre editorial. No demuestra, por sí solo, que el XML resultante cumpla el perfil de SciELO o el flujo de Redalyc.[1][2]

Antes de cambiar la producción de una revista, separa cuatro preguntas: qué versión de OJS está realmente disponible; qué componente genera el XML; qué versión y perfil JATS pide el destino; y qué resultado arroja una prueba con artículos representativos. Confundir esas capas lleva a comprar una expectativa en vez de validar un proceso.

Diagrama propio. El XML JATS generado por una plataforma debe comprobarse contra el destino editorial antes de considerarlo apto para entrega.

OJS 3.6 anuncia producción integrada, no una certificación de destino

PKP describe OJS 3.6 como un flujo que transforma el cuerpo de un DOCX en HTML editable, mantiene el HTML como fuente de producción y puede generar galeradas HTML, PDF y XML JATS bajo demanda.[1] También aclara que la primera entrega estaba programada para otoño de 2026 y que el flujo tradicional con herramientas de escritorio o servicios externos sigue disponible.[1][2]

Ese anuncio importa. Una revista podría corregir el cuerpo del artículo en el editor integrado y regenerar archivos sin repetir una cadena completa de conversiones. Sin embargo, la promesa técnica publicada es una salida JATS desde el flujo de OJS. PKP menciona JATS para indexación y archivo, con PubMed como ejemplo, pero no afirma en esos anuncios que el resultado esté certificado para SciELO Publishing Schema, aceptado por una colección SciELO o preparado para ingresar a Redalyc.[2]

La diferencia no es semántica. "Se puede descargar XML JATS" responde una pregunta sobre formato. "Este paquete puede entregarse a SciELO o Redalyc" responde una pregunta sobre un destino, sus reglas y su proceso de aceptación.

La página de lanzamientos de PKP, consultada para este artículo, lista OJS 3.5 como versión LTS soportada y explica que las versiones pares, como 3.6, corresponden a la línea STS.[3] El endpoint público de GitHub Releases de pkp/ojs devolvía una lista vacía al momento de la consulta.[4] Esa respuesta no prueba que no exista una compilación de prueba o una etiqueta en otro canal. Sí impide presentar una versión estable 3.6 como un hecho comprobado desde ese endpoint.

JATS válido, XML SciELO y XML Redalyc no son equivalentes

JATS es una familia de modelos XML para artículos académicos. SciELO Publishing Schema agrega reglas especializadas al uso de JATS para el enfoque SciELO. La documentación de SciELO describe el esquema como una combinación de NISO JATS Journal Publishing DTD y reglas propias del estilo SciELO.[5]

Por eso, pasar una validación JATS genérica no basta para concluir que un archivo cumple SciELO. La documentación de SciELO señala que el XML entregado debe ajustarse a SciELO PS y mantiene herramientas para revisar conformidad, como StyleChecker, además de herramientas de paquetes y reportes.[5][6] El perfil aplicable puede depender de la colección y de sus instrucciones vigentes. Ese dato debe quedar escrito en la prueba y en el alcance de producción; no basta con poner "XML JATS" en una cotización o en una lista de entregables.

Redalyc tampoco debe tratarse como un sinónimo de SciELO. La ayuda de Marcalyc, plataforma de Redalyc, distingue un XML JATS4R y un XML adaptado al esquema SciELO; también mantiene documentación específica de su sistema de marcado y sus productos.[7] Esa distinción basta para una regla operativa: si la revista necesita más de un destino, cada destino debe tener requisitos, evidencia de validación y responsable de cierre propios.

No afirmes que el XML de OJS 3.6 "no sirve". La conclusión honesta es más útil: todavía no hay evidencia pública, en los anuncios revisados de PKP, de conformidad con el perfil técnico y el proceso de aceptación de cada destino. Esa conformidad se demuestra con pruebas y registros, no con el nombre del formato.

El plugin JATS Template es una señal, no la prueba del nuevo flujo

El repositorio oficial pkp/jatsTemplate merece atención, pero no se debe usar para describir automáticamente la nueva producción desde HTML de OJS 3.6. Son componentes y trayectorias que deben comprobarse por separado en una instalación de prueba.

El README del plugin dice que genera un documento JATS básico a partir de metadatos de OJS y extracción de texto completo cuando no existe un JATS mejor. También advierte que el XML que produce no está pensado para publicación sin mejoras y control de calidad adicionales. Para OJS 3.6.0.x, el repositorio declara JATS 1.2 válido.[8]

Eso permite extraer dos conclusiones prudentes:

• La validez JATS de un componente no acredita, por sí misma, la calidad editorial ni un destino específico.
• No se puede decir que el nuevo exportador de OJS 3.6 produce exactamente lo mismo que este plugin hasta inspeccionar la versión instalada, sus dependencias, el XML de salida y su documentación de liberación.

Separar ambos asuntos evita dos errores opuestos: vender cualquier XML de OJS como apto para publicación especializada, o descalificar una función nueva sin haberla probado.

La base de datos de OJS y el JATS no se sincronizan automáticamente

Esta es una limitación práctica que afecta a metadatos y correcciones. PKP indica que, en el estado que describe para OJS 3.6, los metadatos JATS y la base de datos de OJS no están vinculados; una actualización en OJS no se reflejaría automáticamente en el JATS.[1]

La revista debe decidir cuál será la fuente autorizada de cada dato y registrar qué archivo requiere regeneración después de una corrección. Considera, por ejemplo, una afiliación, un ORCID, una referencia o una licencia. Si el editor modifica el registro de OJS, debe comprobar si esa modificación llegó al XML descargable, al HTML y al PDF. Si el cambio se hizo dentro del archivo de producción, debe verificar qué dato quedó finalmente en OJS.

No es un motivo para descartar OJS 3.6. Es una condición de operación. Sin un responsable para la sincronización y la revisión de versiones, una revista puede publicar salidas técnicamente bien formadas que contienen metadatos diferentes entre sí.

Qué debe probar una revista antes de adoptar producción editorial OJS 3.6

La prueba debe trabajar con archivos representativos y una versión identificada de la plataforma. No uses manuscritos en evaluación ni datos personales sin autorización. Si no existen artículos publicados que sirvan, crea muestras sintéticas que reproduzcan la complejidad editorial.

Registra, como mínimo:

1. La versión exacta de OJS, commit o paquete instalado, plugins habilitados y configuración que participa en la generación.
2. Cinco artículos con dificultad diferente: autorías y afiliaciones múltiples, referencias heterogéneas, tabla compleja, figura, fórmula, material suplementario o más de un idioma, según corresponda a la revista.
3. El XML, HTML y PDF obtenidos antes de correcciones. Conserva esos primeros resultados para distinguir lo que produjo la herramienta de lo que corrigió una persona.
4. Integridad de título, autorías, afiliaciones, ORCID, DOI, resúmenes, referencias, tablas, figuras, fórmulas y enlaces. PKP advierte que estilos complejos o atípicos podrían no transformarse de forma perfecta, aunque informa preservación de tablas y fórmulas durante la transformación.[1]
5. La validación del destino. Para SciELO, aplica la versión SPS y las herramientas o revisión que indique la colección. Para Redalyc, usa las instrucciones y el flujo propio del destino, no una validación de SciELO como sustituto.
6. Cada corrección humana, quién la autorizó, qué archivo cambió y cuánto trabajo adicional fue necesario para llegar a un paquete aceptable para la revista.

El número de cinco artículos no prueba un resultado universal. Es una muestra de decisión. Sirve para descubrir fallas repetidas antes de comprometer un número completo o cambiar la rutina de producción.

OJS 3.6 y Jatson pueden complementarse, si la prueba lo demuestra

OJS 3.6 puede resolver producción integrada para revistas cuyo flujo y casos reales pasen las pruebas acordadas. El rol de Jatson no debe presentarse como competir con cada salida nativa de OJS. En una revista con exigencias de destino, puede aportar una etapa especializada de preparación, verificación y producción editorial.

OJS ONE describe Jatson como un flujo que recibe el artículo aceptado y produce XML JATS, PDF editorial y HTML, con validación estructural y revisión editorial antes de la entrega.[9] Esa descripción no equivale a una certificación externa ni permite afirmar compatibilidad con cualquier perfil. Su utilidad se debe comprobar contra el destino y la muestra de cada revista.

Criterio de decisión	OJS 3.6 según evidencia pública	Jatson según información publicada	Qué falta comprobar
Fuente de producción	PKP anuncia HTML como fuente de producción desde el cuerpo DOCX.[1][2]	OJS ONE describe un flujo desde artículo aceptado, metadatos y recursos hacia XML, PDF y HTML.[9]	Si los resultados equivalen en una muestra real.
XML JATS	PKP anuncia una salida JATS descargable; su flujo no es JATS-céntrico.[1]	OJS ONE declara producción y revisión de XML JATS.[9]	Perfil JATS, controles aplicados y resultado por destino.
SciELO y Redalyc	Los anuncios de PKP revisados no acreditan SPS ni un flujo de Redalyc.	La página de Jatson declara preparación para SciELO Chile, no una certificación universal.[9]	Colección, validadores, paquete y aceptación del destino.
Corrección de metadatos	PKP señala que OJS y JATS no se actualizan automáticamente entre sí.[1]	No hay medición publicada aquí sobre propagación de cambios.	Qué se regenerará y quién aprobará la versión final.

Existe además una posibilidad técnica que vale la pena ensayar: usar el JATS generado por OJS 3.6 como insumo de revisión o enriquecimiento, en vez de obligar a que ambos procesos compitan desde el inicio. El piloto debería responder preguntas concretas: ¿qué metadatos conserva OJS?, ¿qué estructura o recursos requieren ajuste?, ¿qué cambios deben volver a OJS?, ¿qué salida finalmente aprueba el destino? Esa posibilidad es una hipótesis de integración, no una capacidad que OJS ONE deba prometer antes de implementarla y medirla.

Para profundizar en responsabilidades de producción, revisa la guía sobre externalizar marcación XML JATS para SciELO y el artículo sobre errores que un XML válido puede conservar. Ambos ayudan a definir evidencias, aprobaciones y correcciones, pero no sustituyen la prueba de OJS 3.6.

Errores que conviene evitar al evaluar OJS 3.6 XML JATS SciELO

El primer error es presentar una hoja de ruta como una función estable ya operando en la revista. Mantén separada la fecha del anuncio, la versión de prueba y la versión que se autoriza para producción.

El segundo es llamar "SciELO" a cualquier XML JATS. Pide el perfil, la colección, el control aplicado y el reporte de resultado. La estructura XML puede ser correcta y aun así no resolver requisitos del paquete o de los metadatos del destino.

El tercero es revisar solo una salida. El XML, el HTML, el PDF y los datos de OJS deben contar la misma historia después de una corrección. Si difieren, el problema es de control de versiones, aunque cada archivo abra sin error.

El cuarto es comparar OJS y Jatson solo por el número de formatos que cada uno enumera. La comparación útil mide el paquete que llega a la revista, las correcciones necesarias, las responsabilidades y la evidencia de conformidad que exige el destino.

Preguntas frecuentes

¿OJS 3.6 generará XML JATS para SciELO?

PKP anunció generación de XML JATS desde HTML para OJS 3.6.[1][2] SciELO exige conformidad con su Publishing Schema y controles de validación propios.[5][6] Por eso, una revista debe probar la salida de la versión concreta de OJS contra los requisitos de su colección antes de asumir que puede entregarla a SciELO.

¿Un XML JATS válido puede ser rechazado por SciELO o Redalyc?

Sí, porque la validez general de JATS no demuestra que el archivo cumpla un perfil especializado, incluya los datos que pide el destino o complete su proceso de paquete y revisión. SciELO PS agrega reglas al uso de JATS, y Marcalyc diferencia salidas JATS4R y XML para SciELO.[5][7]

¿Jatson reemplazará el flujo de producción de OJS 3.6?

No debe plantearse como un reemplazo automático. OJS 3.6 puede ser adecuado para ciertos flujos integrados. Jatson puede ser pertinente cuando una revista necesita producción especializada, controles adicionales o una preparación técnica que la prueba haya mostrado necesaria. La elección depende de los artículos de muestra y del destino acordado.

Evalúa la salida antes de cambiar el proceso

Una revista puede preparar el piloto sin mover su producción actual. Define artículos de muestra, destino, criterios de aceptación y evidencias de cierre. Si necesitas revisar el flujo de salida o preparar XML JATS, PDF y HTML desde artículos aceptados, conoce OJS One Jatson. El alcance debe confirmarse según la revista, los insumos y el destino técnico requerido.

Fuentes

1. PKP, Upload, Transform, Publish: Inside OJS 3.6's File Production and Toolset — consultado 2026-10-25.
2. PKP, OJS 3.6: Bringing Manuscript Editing and Production under one Roof — consultado 2026-10-25.
3. PKP, PKP Software Releases — consultado 2026-10-25.
4. GitHub API, pkp/ojs releases — consultado 2026-10-25.
5. SciELO, Guia de uso de elementos e atributos XML para documentos que seguem a implementação SciELO Publishing Schema — consultado 2026-10-25.
6. SciELO, Perguntas Frequentes Sobre a Adoção de XML — consultado 2026-10-25.
7. Marcalyc, Aprende a usar Marcalyc — consultado 2026-10-25.
8. PKP, JATS Template Plugin — consultado 2026-10-25.
9. OJS ONE, OJS One Jatson — consultado 2026-10-25.