OJS 3.6 JATS SciELO: qué revisar antes de producir

OJS 3.6 JATS SciELO: qué revisar antes de producir

OJS 3.6 JATS SciELO no es una decisión de activar una salida y dejar de mirar el archivo. La versión propuesta por PKP transforma el contenido del envío a HTML editable y permite generar JATS desde ese HTML; para una revista que trabaja con SciELO, el paso útil es verificar el perfil de salida y el paquete antes de incorporarlo al ciclo editorial.[1]

La pregunta correcta no es si una salida JATS es suficiente por sí sola. Conviene separar tres planos: XML JATS válido, conformidad con SciELO Publishing Schema (SciELO PS) y control editorial del artículo. Cada plano detecta riesgos distintos y exige evidencias distintas.[2][3]

Diagrama propio. Cada control deja su propio informe y su responsable; ninguno reemplaza a los demás.

OJS 3.6 JATS SciELO: controla el HTML de partida

La generación de JATS en OJS 3.6 se apoya en una cadena de transformación, no en una corrección automática de la información editorial. PKP describe el paso desde DOCX a HTML editable del cuerpo del artículo, junto con metadatos estructurados almacenados en OJS. También indica que esa conversión genera HTML compatible con JATS, desde el cual el mapeo hacia JATS y su actualización resultan directos.[1]

Esa arquitectura tiene una consecuencia práctica: el equipo no debería revisar solo el XML final. Debe abrir el HTML que funcionó como fuente, contrastarlo con el manuscrito aprobado y confirmar que los elementos que interesan a la revista quedaron expresados de forma inequívoca. Un encabezado con jerarquía confusa, una tabla mal interpretada o una imagen sin descripción pueden entrar a la cadena antes de que aparezca el XML.

PKP advierte que estilos complejos o atípicos pueden no transformarse perfectamente, aunque la herramienta continúe mejorando. Por eso, la primera muestra no debiera contener solo artículos simples. Es preferible incluir un texto con secciones, citas, tabla, figura, ecuación si la revista las publica, autores con afiliaciones y referencias de distinta forma. El objetivo es saber qué hace la salida con material que representa la práctica editorial real.[1]

La misma fuente establece un límite importante: el flujo centrado en JATS, donde una entidad externa crea JATS desde DOCX y ese XML pasa a ser la fuente para HTML y PDF, no está incluido en OJS 3.6. Eso no impide usar producción externa; evita confundir el flujo HTML de OJS con aquel esquema de producción.[1]

Distingue XML JATS válido, SciELO PS y QA editorial

Un XML JATS válido responde a una gramática JATS determinada. El repositorio del plugin JATS Template de PKP señala que, desde OJS 3.6.0.x, el plugin genera XML JATS 1.2 válido. Esa condición es valiosa como prueba de estructura, pero no convierte por sí misma el archivo en un paquete ajustado a otro perfil de intercambio.[2]

SciELO describe otra exigencia: el XML que necesita debe estar en conformidad con SciELO Publishing Schema. Su documentación explica que ese esquema reúne DTD JATS 1.0, especificaciones PMC y estilo SciELO; es decir, especializa aspectos de la especificación para el envío de documentos.[3]

El tercer plano es editorial. Un archivo puede respetar una gramática y, aun así, traer una referencia incompleta, una afiliación asignada a la persona equivocada, una figura con rótulo insuficiente o una fecha que no corresponde a la decisión editorial. Ninguna de esas situaciones se resuelve al mirar únicamente un mensaje de validación estructural. La revisión debe comparar la salida con la versión aprobada y con los datos que la revista decidió publicar.

La diferencia también aparece en el propio plugin de PKP. Su README explica que entrega una plantilla básica cuando no hay un JATS de mayor calidad disponible y que no está pensada para publicación sin mejoras y control de calidad considerable.[2] Léelo como una señal de alcance: «válido» describe una condición técnica; no reemplaza una revisión de contenido, estilo o empaquetado.

Define el perfil de salida antes de generar el primer archivo

El perfil de salida es la especificación operativa que la revista fijará para evaluar cada resultado. No basta con decir «JATS». Escribe qué versión, qué elementos editoriales deben estar presentes, cómo se representarán identificadores, qué información se conservará para figuras y tablas, qué forma esperan las referencias y qué documentos acompañan al XML.

Este perfil debe unir tres referencias: las decisiones editoriales de la revista, el comportamiento observado de la transformación HTML–JATS de OJS y las reglas de SciELO PS que correspondan al paquete que se preparará. No asumas que un dato visible en OJS aparece igual en JATS. PKP dice expresamente que los metadatos de JATS y la base de datos de OJS no están vinculados; por ello, un cambio en OJS no se reflejará en JATS.[1]

Ese punto merece un control de versiones. Antes de publicar, anota qué cambio se hizo en OJS, cuándo se regeneró la salida y cuál es el archivo que se revisó. Si se corrige el título, la autoría, el DOI, una referencia o un dato de licencia después de generar JATS, vuelve a generar y vuelve a comparar. Así se evita aprobar una copia y cargar otra.

Una pauta breve para el perfil de salida puede incluir:

• datos bibliográficos que deben coincidir entre OJS, HTML y XML;
• estructura del cuerpo: título, resumen, secciones, tablas, figuras y referencias;
• tratamiento de afiliaciones, identificadores y notas de autoría;
• elementos que exigen revisión humana según la tipología de la revista;
• versión de la salida, responsable de revisión y evidencia de validación.

Revisa el paquete, no solo el XML aislado

Para SciELO, la unidad práctica de revisión no es una etiqueta suelta. La documentación de SciELO indica que Package Maker informa problemas posibles, renombra archivos conforme al patrón SciELO PS y los separa en paquetes. StyleChecker, a su vez, entrega un informe detallado de conformidad de un XML respecto de SciELO PS.[3]

Por ello, la revista debe probar la construcción del paquete completo: nombre y ubicación de archivos, XML, activos gráficos, tablas o material complementario si aplica, y coherencia de las referencias hacia dichos activos. La revisión de paquete responde preguntas que un chequeo aislado no cubre: ¿el XML apunta al recurso correcto?, ¿cada nombre se ajusta a la convención requerida?, ¿la evidencia de validación corresponde a esa misma versión del artículo?

Usa las herramientas de SciELO como controles de conformidad del perfil, no como una declaración de aceptación. Su documentación señala que ambas se usan en producción y publicación según SciELO PS, y que la validación se mantiene en cada envío incluso después de una certificación de proveedor.[3] Para la revista, la conclusión operativa es más sobria: conserva el informe, corrige lo que indique y vuelve a ejecutarlo sobre el paquete regenerado.

Ejecuta una muestra de prueba con casos que tensionen el flujo

La muestra de prueba debe parecerse al material que dará más trabajo, no a un artículo ideal. Elige artículos ya aprobados para una prueba interna, sin publicarlos mediante el nuevo flujo hasta concluir la revisión. Incluye variedad de estructura, material gráfico, autores con varias afiliaciones y referencias con tipos diversos. Si la revista usa resúmenes en más de un idioma o suplementos, añádelos a la muestra.

La secuencia recomendada es simple:

1. Define el perfil de salida y una planilla de comparación.
2. Genera HTML y JATS desde una copia controlada del artículo.
3. Revisa visualmente HTML y PDF cuando sean parte del flujo, contra el documento editorial aprobado.
4. Valida el XML contra la condición JATS que la herramienta declare.
5. Construye y revisa el paquete con las herramientas de SciELO correspondientes.[3]
6. Corrige en la fuente adecuada, regenera y repite los controles.
7. Guarda XML, paquete, informes y decisión editorial bajo una versión identificable.

No saltes del paso 2 al 5. Si el problema nace en el contenido o en la transformación a HTML, arreglar solo el XML puede crear divergencias entre archivos. La fuente de PKP presenta el HTML como la fuente canónica de producción para generar salidas; esa es una razón práctica para localizar primero dónde se originó la diferencia.[1]

Organiza controles por responsable y por momento

La calidad mejora cuando cada control tiene un responsable y un momento definidos. El editor o editora valida contenido, metadatos visibles, autoría y referencias contra la versión aprobada. La persona a cargo de producción revisa estructura, archivos asociados, salida HTML/PDF y reportes técnicos. Quien administra OJS comprueba que la versión cargada es la aprobada y que una modificación posterior no dejó el XML desactualizado.

El reporte técnico no reemplaza una decisión editorial. La revisión editorial tampoco debe ocultar un problema de empaquetado. Una pauta de liberación debe tener casillas separadas para: coincidencia editorial, validez JATS, conformidad SciELO PS, integridad del paquete y versión final cargada. Cuando una casilla falla, el artículo vuelve a la etapa que puede corregirla.

Enlaza este control con tu guía de automatización editorial y con la revisión de errores XML JATS. Son apoyos para documentar el flujo interno; no sustituyen la evidencia del archivo y paquete revisados.

Errores comunes que conviene evitar

El primer error es tratar “JATS válido” como sinónimo de “conforme a SciELO PS”. Son verificaciones relacionadas, pero no equivalentes: una mira la gramática JATS; la otra contrasta el archivo con el esquema y estilo de SciELO.[2][3]

El segundo es modificar metadatos en OJS después de generar el XML y asumir sincronización. PKP informa que los metadatos de JATS y la base de datos de OJS no están enlazados.[1] La medida concreta es regenerar, comparar y archivar el nuevo informe.

El tercero es probar con un único manuscrito sencillo. Ese resultado no muestra cómo responde la cadena a figuras, tablas, estilos complejos o referencias variadas. PKP reconoce límites de transformación para estilos complejos o poco usuales.[1]

El cuarto es separar validación técnica y revisión editorial como si una bastara. El plugin de plantilla básica de PKP exige mejoras adicionales y control de calidad antes de una finalidad de publicación.[2]

Conclusión: una salida usable se demuestra con evidencia

OJS 3.6 abre una vía para generar JATS desde HTML editable y mantener un flujo de archivos más integrado.[1] Para una revista que opera con SciELO, la decisión responsable es convertir esa capacidad en una prueba controlada: perfil de salida escrito, muestra representativa, validación JATS, revisión contra SciELO PS, verificación del paquete y control editorial de la versión liberada.[2][3]

El resultado buscado no es una afirmación general sobre compatibilidad ni una promesa de aceptación. Es evidencia repetible de que la revista puede revisar, corregir y documentar cada salida antes de usarla en producción.

Preguntas frecuentes

¿OJS 3.6 puede generar XML JATS desde HTML?

PKP describe un flujo donde el cuerpo del DOCX se convierte en HTML editable y compatible con JATS, con generación de JATS desde esa base.[1] Antes de depender de esa salida, pruébala con artículos representativos de tu revista y revisa el resultado completo.

¿Un XML JATS válido ya cumple con SciELO PS?

No son la misma comprobación. PKP informa validez JATS 1.2 para su plugin desde OJS 3.6.0.x, mientras SciELO exige conformidad con SciELO Publishing Schema.[2][3] Ejecuta la validación del perfil SciELO y conserva su informe junto al paquete.

¿Qué debería guardar después de validar una muestra?

Guarda la versión del artículo usada, HTML y XML generados, paquete, informes de las herramientas, pauta editorial y registro de correcciones. Esa evidencia permite saber qué se evaluó y repetir la verificación si se modifica contenido o metadatos.

Producción especializada cuando el flujo requiere más control

Si tu equipo necesita una capa de producción especializada, Jatson se presenta como un complemento entre el manuscrito y la publicación: recibe el contenido fuente, lo estructura, lo valida y lo convierte en XML JATS, PDF editorial y Scholarly HTML para OJS.[4] Puede ser una alternativa para evaluar cuando la revista busca separar la producción especializada de la administración cotidiana de OJS. Solicita una evaluación del flujo y del paquete que tu revista necesita, sin asumir resultados antes de revisar una muestra.

Fuentes

1. PKP, Upload, Transform, Publish: Inside OJS 3.6’s File Production and Toolset — consultado 2026-10-23.
2. PKP, JATS Template Plugin — consultado 2026-10-23.
3. SciELO, Perguntas Frequentes Sobre a Adoção de XML — consultado 2026-10-23.
4. OJS ONE, Marcación XML JATS para SciELO Chile — consultado 2026-10-23.