OJS 3.6 XML JATS SciELO: serve para a SciELO ou para a Redalyc?

OJS 3.6 XML JATS SciELO: serve para a SciELO ou para a Redalyc?

OJS 3.6 XML JATS SciELO é uma combinação que já desperta expectativas legítimas. O PKP anunciou que sua próxima versão poderá produzir HTML, PDF e XML JATS a partir de HTML estruturado. Isso pode simplificar uma parte do fechamento editorial. Não demonstra, por si só, que o XML resultante cumpra o perfil da SciELO ou o fluxo da Redalyc.[1][2]

Antes de mudar a produção de uma revista, separe quatro perguntas: qual versão do OJS está realmente disponível; qual componente gera o XML; qual versão e perfil JATS o destino exige; e qual resultado um teste com artigos representativos produz. Confundir essas camadas leva a comprar uma expectativa em vez de validar um processo.

Diagrama próprio. O XML JATS gerado por uma plataforma deve ser verificado contra o destino editorial antes de ser considerado apto para entrega.

O OJS 3.6 anuncia produção integrada, não uma certificação de destino

O PKP descreve o OJS 3.6 como um fluxo que transforma o corpo de um DOCX em HTML editável, mantém o HTML como fonte de produção e pode gerar provas em HTML, PDF e XML JATS sob demanda.[1] Também esclarece que a primeira entrega estava programada para o outono de 2026 e que o fluxo tradicional com ferramentas de desktop ou serviços externos continua disponível.[1][2]

Esse anúncio importa. Uma revista poderia corrigir o corpo do artigo no editor integrado e gerar os arquivos de novo sem repetir uma cadeia completa de conversões. No entanto, a promessa técnica publicada é uma saída JATS a partir do fluxo do OJS. O PKP menciona o JATS para indexação e arquivamento, com o PubMed como exemplo, mas não afirma nesses anúncios que o resultado esteja certificado para o SciELO Publishing Schema, aceito por uma coleção SciELO ou pronto para ingressar na Redalyc.[2]

A diferença não é semântica. "É possível baixar XML JATS" responde a uma pergunta sobre formato. "Este pacote pode ser entregue à SciELO ou à Redalyc" responde a uma pergunta sobre um destino, suas regras e seu processo de aceitação.

A página de lançamentos do PKP, consultada para este artigo, lista o OJS 3.5 como versão LTS com suporte e explica que as versões pares, como a 3.6, correspondem à linha STS.[3] O endpoint público de GitHub Releases do pkp/ojs retornava uma lista vazia no momento da consulta.[4] Essa resposta não prova que não exista uma compilação de teste ou uma etiqueta em outro canal. Ela impede, sim, apresentar uma versão estável 3.6 como um fato comprovado a partir desse endpoint.

JATS válido, XML SciELO e XML Redalyc não são equivalentes

O JATS é uma família de modelos XML para artigos acadêmicos. O SciELO Publishing Schema acrescenta regras especializadas ao uso do JATS para a abordagem SciELO. A documentação da SciELO descreve o esquema como uma combinação da NISO JATS Journal Publishing DTD e de regras próprias do estilo SciELO.[5]

Por isso, passar por uma validação JATS genérica não basta para concluir que um arquivo cumpre a SciELO. A documentação da SciELO indica que o XML entregue deve se ajustar ao SciELO PS e mantém ferramentas para verificar a conformidade, como o StyleChecker, além de ferramentas de pacotes e relatórios.[5][6] O perfil aplicável pode depender da coleção e de suas instruções vigentes. Esse dado deve ficar escrito no teste e no escopo de produção; não basta pôr "XML JATS" em um orçamento ou em uma lista de entregáveis.

A Redalyc tampouco deve ser tratada como sinônimo da SciELO. A ajuda do Marcalyc, plataforma da Redalyc, distingue um XML JATS4R de um XML adaptado ao esquema SciELO; também mantém documentação específica de seu sistema de marcação e de seus produtos.[7] Essa distinção basta para uma regra operacional: se a revista precisa de mais de um destino, cada destino deve ter requisitos, evidência de validação e responsável pelo encerramento próprios.

Não afirme que o XML do OJS 3.6 "não serve". A conclusão honesta é mais útil: ainda não há evidência pública, nos anúncios revisados do PKP, de conformidade com o perfil técnico e o processo de aceitação de cada destino. Essa conformidade se demonstra com testes e registros, não com o nome do formato.

O plugin JATS Template é um sinal, não a prova do novo fluxo

O repositório oficial pkp/jatsTemplate merece atenção, mas não deve ser usado para descrever automaticamente a nova produção a partir do HTML do OJS 3.6. São componentes e trajetórias que devem ser verificados separadamente em uma instalação de teste.

O README do plugin diz que ele gera um documento JATS básico a partir de metadados do OJS e extração de texto completo quando não existe um JATS melhor. Também adverte que o XML que produz não se destina à publicação sem melhorias e controle de qualidade adicionais. Para o OJS 3.6.0.x, o repositório declara JATS 1.2 válido.[8]

Isso permite extrair duas conclusões prudentes:

• A validade JATS de um componente não comprova, por si só, a qualidade editorial nem um destino específico.
• Não se pode dizer que o novo exportador do OJS 3.6 produz exatamente o mesmo que esse plugin até inspecionar a versão instalada, suas dependências, o XML de saída e sua documentação de lançamento.

Separar os dois assuntos evita dois erros opostos: vender qualquer XML do OJS como apto para publicação especializada, ou desqualificar uma função nova sem tê-la testado.

O banco de dados do OJS e o JATS não se sincronizam automaticamente

Esta é uma limitação prática que afeta metadados e correções. O PKP indica que, no estado que descreve para o OJS 3.6, os metadados JATS e o banco de dados do OJS não estão vinculados; uma atualização no OJS não seria refletida automaticamente no JATS.[1]

A revista deve decidir qual será a fonte autorizada de cada dado e registrar qual arquivo exige nova geração depois de uma correção. Considere, por exemplo, uma afiliação, um ORCID, uma referência ou uma licença. Se o editor modifica o registro do OJS, deve verificar se essa modificação chegou ao XML baixável, ao HTML e ao PDF. Se a mudança foi feita dentro do arquivo de produção, deve verificar qual dado ficou finalmente no OJS.

Não é um motivo para descartar o OJS 3.6. É uma condição de operação. Sem um responsável pela sincronização e pela revisão de versões, uma revista pode publicar saídas tecnicamente bem formadas que contêm metadados diferentes entre si.

O que uma revista deve testar antes de adotar a produção editorial do OJS 3.6

O teste deve trabalhar com arquivos representativos e uma versão identificada da plataforma. Não use manuscritos em avaliação nem dados pessoais sem autorização. Se não existirem artigos publicados que sirvam, crie amostras sintéticas que reproduzam a complexidade editorial.

Registre, no mínimo:

1. A versão exata do OJS, o commit ou pacote instalado, os plugins habilitados e a configuração que participa da geração.
2. Cinco artigos com dificuldades diferentes: autorias e afiliações múltiplas, referências heterogêneas, tabela complexa, figura, fórmula, material suplementar ou mais de um idioma, conforme o caso da revista.
3. O XML, o HTML e o PDF obtidos antes das correções. Guarde esses primeiros resultados para distinguir o que a ferramenta produziu do que uma pessoa corrigiu.
4. Integridade de título, autorias, afiliações, ORCID, DOI, resumos, referências, tabelas, figuras, fórmulas e links. O PKP adverte que estilos complexos ou atípicos podem não ser transformados perfeitamente, embora informe a preservação de tabelas e fórmulas durante a transformação.[1]
5. A validação do destino. Para a SciELO, aplique a versão SPS e as ferramentas ou a revisão que a coleção indicar. Para a Redalyc, use as instruções e o fluxo próprios do destino, e não uma validação da SciELO como substituta.
6. Cada correção humana, quem a autorizou, qual arquivo mudou e quanto trabalho adicional foi necessário para chegar a um pacote aceitável para a revista.

O número de cinco artigos não prova um resultado universal. É uma amostra de decisão. Serve para descobrir falhas repetidas antes de comprometer um número completo ou mudar a rotina de produção.

O OJS 3.6 e o Jatson podem se complementar, se o teste demonstrar

O OJS 3.6 pode resolver a produção integrada para revistas cujo fluxo e casos reais passem pelos testes acordados. O papel do Jatson não deve ser apresentado como competir com cada saída nativa do OJS. Em uma revista com exigências de destino, pode oferecer uma etapa especializada de preparação, verificação e produção editorial.

A OJS ONE descreve o Jatson como um fluxo que recebe o artigo aceito e produz XML JATS, PDF editorial e HTML, com validação estrutural e revisão editorial antes da entrega.[9] Essa descrição não equivale a uma certificação externa nem permite afirmar compatibilidade com qualquer perfil. Sua utilidade deve ser verificada contra o destino e a amostra de cada revista.

Critério de decisão	OJS 3.6 segundo a evidência pública	Jatson segundo a informação publicada	O que falta verificar
Fonte de produção	O PKP anuncia o HTML como fonte de produção a partir do corpo DOCX.[1][2]	A OJS ONE descreve um fluxo do artigo aceito, metadados e recursos para XML, PDF e HTML.[9]	Se os resultados equivalem em uma amostra real.
XML JATS	O PKP anuncia uma saída JATS baixável; seu fluxo não é centrado em JATS.[1]	A OJS ONE declara produção e revisão de XML JATS.[9]	Perfil JATS, controles aplicados e resultado por destino.
SciELO e Redalyc	Os anúncios do PKP revisados não comprovam o SPS nem um fluxo da Redalyc.	A página do Jatson declara preparação para a SciELO Chile, não uma certificação universal.[9]	Coleção, validadores, pacote e aceitação do destino.
Correção de metadados	O PKP aponta que o OJS e o JATS não se atualizam automaticamente entre si.[1]	Não há medição publicada aqui sobre a propagação de mudanças.	O que será gerado de novo e quem aprovará a versão final.

Existe ainda uma possibilidade técnica que vale a pena testar: usar o JATS gerado pelo OJS 3.6 como insumo de revisão ou enriquecimento, em vez de obrigar os dois processos a competir desde o início. O piloto deveria responder a perguntas concretas: quais metadados o OJS conserva? Que estrutura ou recursos exigem ajuste? Quais mudanças devem voltar ao OJS? Qual saída o destino finalmente aprova? Essa possibilidade é uma hipótese de integração, não uma capacidade que a OJS ONE deva prometer antes de implementá-la e medi-la.

Para aprofundar as responsabilidades de produção, consulte o guia sobre terceirizar a marcação XML JATS para a SciELO e o artigo sobre erros que um XML válido pode manter. Ambos ajudam a definir evidências, aprovações e correções, mas não substituem o teste do OJS 3.6.

Erros que convém evitar ao avaliar o OJS 3.6 XML JATS SciELO

O primeiro erro é apresentar um roteiro como uma função estável já operando na revista. Mantenha separadas a data do anúncio, a versão de teste e a versão autorizada para produção.

O segundo é chamar de "SciELO" qualquer XML JATS. Peça o perfil, a coleção, o controle aplicado e o relatório de resultado. A estrutura XML pode estar correta e, ainda assim, não resolver requisitos do pacote ou dos metadados do destino.

O terceiro é revisar apenas uma saída. O XML, o HTML, o PDF e os dados do OJS devem contar a mesma história depois de uma correção. Se diferem, o problema é de controle de versões, mesmo que cada arquivo abra sem erro.

O quarto é comparar OJS e Jatson apenas pelo número de formatos que cada um enumera. A comparação útil mede o pacote que chega à revista, as correções necessárias, as responsabilidades e a evidência de conformidade que o destino exige.

Perguntas frequentes

O OJS 3.6 vai gerar XML JATS para a SciELO?

O PKP anunciou a geração de XML JATS a partir de HTML para o OJS 3.6.[1][2] A SciELO exige conformidade com seu Publishing Schema e controles de validação próprios.[5][6] Por isso, uma revista deve testar a saída da versão concreta do OJS contra os requisitos de sua coleção antes de presumir que pode entregá-la à SciELO.

Um XML JATS válido pode ser rejeitado pela SciELO ou pela Redalyc?

Sim, porque a validade geral do JATS não demonstra que o arquivo cumpra um perfil especializado, inclua os dados que o destino pede ou complete seu processo de pacote e revisão. O SciELO PS acrescenta regras ao uso do JATS, e o Marcalyc diferencia saídas JATS4R de XML para a SciELO.[5][7]

O Jatson vai substituir o fluxo de produção do OJS 3.6?

Não deve ser colocado como uma substituição automática. O OJS 3.6 pode ser adequado para certos fluxos integrados. O Jatson pode ser pertinente quando uma revista precisa de produção especializada, controles adicionais ou uma preparação técnica que o teste tenha mostrado necessária. A escolha depende dos artigos de amostra e do destino acordado.

Avalie a saída antes de mudar o processo

Uma revista pode preparar o piloto sem mover sua produção atual. Defina artigos de amostra, destino, critérios de aceitação e evidências de encerramento. Se você precisa revisar o fluxo de saída ou preparar XML JATS, PDF e HTML a partir de artigos aceitos, conheça o OJS One Jatson. O escopo deve ser confirmado conforme a revista, os insumos e o destino técnico exigido.

Fontes

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