OJS 3.6 JATS XML SciELO: Does It Work for SciELO or Redalyc?

OJS 3.6 JATS XML SciELO: Does It Work for SciELO or Redalyc?

OJS 3.6 JATS XML SciELO is a combination that already raises legitimate expectations. PKP announced that its next version will be able to produce HTML, PDF and JATS XML from structured HTML. That can simplify part of the editorial closing process. It does not show, on its own, that the resulting XML meets SciELO's profile or Redalyc's workflow.[1][2]

Before changing a journal's production, separate four questions: which OJS version is actually available; which component generates the XML; which JATS version and profile the target asks for; and what result a test with representative articles produces. Confusing those layers leads to buying an expectation instead of validating a process.

Original diagram. The JATS XML generated by a platform must be checked against the editorial target before it is considered fit for delivery.

OJS 3.6 announces integrated production, not a target certification

PKP describes OJS 3.6 as a workflow that transforms the body of a DOCX into editable HTML, keeps HTML as the production source and can generate HTML, PDF and JATS XML galleys on demand.[1] It also clarifies that the first release was scheduled for autumn 2026 and that the traditional workflow with desktop tools or external services remains available.[1][2]

That announcement matters. A journal could correct the body of the article in the integrated editor and regenerate files without repeating a full chain of conversions. However, the technical promise published is a JATS output from the OJS workflow. PKP mentions JATS for indexing and archiving, with PubMed as an example, but it does not state in those announcements that the result is certified for the SciELO Publishing Schema, accepted by a SciELO collection or ready to enter Redalyc.[2]

The difference is not semantic. "You can download JATS XML" answers a question about format. "This package can be delivered to SciELO or Redalyc" answers a question about a target, its rules and its acceptance process.

PKP's releases page, consulted for this article, lists OJS 3.5 as a supported LTS version and explains that even-numbered versions, such as 3.6, belong to the STS line.[3] The public GitHub Releases endpoint for pkp/ojs returned an empty list at the time of the query.[4] That response does not prove that no test build or tag exists in another channel. It does prevent presenting a stable 3.6 version as a fact verified from that endpoint.

Valid JATS, SciELO XML and Redalyc XML are not equivalent

JATS is a family of XML models for scholarly articles. The SciELO Publishing Schema adds specialized rules to the use of JATS for the SciELO approach. SciELO's documentation describes the schema as a combination of the NISO JATS Journal Publishing DTD and rules specific to the SciELO style.[5]

For that reason, passing a generic JATS validation is not enough to conclude that a file complies with SciELO. SciELO's documentation states that the XML delivered must conform to SciELO PS and maintains tools to check conformance, such as StyleChecker, in addition to package and reporting tools.[5][6] The applicable profile may depend on the collection and its current instructions. That detail must be written into the test and the production scope; it is not enough to put "JATS XML" in a quote or in a list of deliverables.

Redalyc should not be treated as a synonym for SciELO either. The help pages of Marcalyc, Redalyc's platform, distinguish a JATS4R XML from an XML adapted to the SciELO schema; they also maintain documentation specific to their markup system and products.[7] That distinction is enough for an operating rule: if the journal needs more than one target, each target must have its own requirements, validation evidence and closing owner.

Do not claim that OJS 3.6's XML "does not work". The honest conclusion is more useful: there is not yet public evidence, in the PKP announcements reviewed, of conformance with the technical profile and acceptance process of each target. That conformance is shown with tests and records, not with the name of the format.

The JATS Template plugin is a signal, not proof of the new workflow

The official pkp/jatsTemplate repository deserves attention, but it should not be used to automatically describe the new production from OJS 3.6 HTML. They are components and paths that must be checked separately in a test installation.

The plugin's README says it generates a basic JATS document from OJS metadata and full-text extraction when no better JATS exists. It also warns that the XML it produces is not intended for publication without further improvements and quality control. For OJS 3.6.0.x, the repository declares valid JATS 1.2.[8]

That allows two prudent conclusions:

• A component's JATS validity does not, by itself, establish editorial quality or fitness for a specific target.
• It cannot be said that OJS 3.6's new exporter produces exactly the same as this plugin until the installed version, its dependencies, the output XML and its release documentation have been inspected.

Separating both matters avoids two opposite mistakes: selling any OJS XML as fit for specialized publication, or dismissing a new function without having tested it.

The OJS database and the JATS do not synchronize automatically

This is a practical limitation that affects metadata and corrections. PKP indicates that, in the state it describes for OJS 3.6, JATS metadata and the OJS database are not linked; an update in OJS would not be automatically reflected in the JATS.[1]

The journal must decide which will be the authoritative source for each data point and record which file needs regeneration after a correction. Consider, for example, an affiliation, an ORCID, a reference or a license. If the editor modifies the OJS record, they must check whether that change reached the downloadable XML, the HTML and the PDF. If the change was made inside the production file, they must verify which data point ended up in OJS.

It is not a reason to discard OJS 3.6. It is an operating condition. Without an owner for synchronization and version review, a journal can publish technically well-formed outputs that contain metadata that differ from one another.

What a journal should test before adopting OJS 3.6 editorial production

The test must work with representative files and an identified version of the platform. Do not use manuscripts under review or personal data without authorization. If there are no published articles that serve, create synthetic samples that reproduce the editorial complexity.

Record, at a minimum:

1. The exact OJS version, commit or installed package, enabled plugins and configuration involved in generation.
2. Five articles of different difficulty: multiple authors and affiliations, heterogeneous references, a complex table, a figure, a formula, supplementary material or more than one language, as applies to the journal.
3. The XML, HTML and PDF obtained before corrections. Keep those first results to distinguish what the tool produced from what a person corrected.
4. Integrity of title, authors, affiliations, ORCID, DOI, abstracts, references, tables, figures, formulas and links. PKP warns that complex or atypical styles might not transform perfectly, although it reports preservation of tables and formulas during the transformation.[1]
5. Validation against the target. For SciELO, apply the SPS version and the tools or review the collection indicates. For Redalyc, use the target's own instructions and workflow, not a SciELO validation as a substitute.
6. Each human correction, who authorized it, which file changed and how much additional work was needed to reach a package acceptable to the journal.

The number of five articles does not prove a universal result. It is a decision sample. It serves to uncover repeated failures before committing a full issue or changing the production routine.

OJS 3.6 and Jatson can complement each other, if the test shows it

OJS 3.6 may solve integrated production for journals whose workflow and real cases pass the agreed tests. Jatson's role should not be presented as competing with every native OJS output. In a journal with target requirements, it can provide a specialized stage of preparation, verification and editorial production.

OJS ONE describes Jatson as a workflow that receives the accepted article and produces JATS XML, editorial PDF and HTML, with structural validation and editorial review before delivery.[9] That description is not an external certification and does not support claiming compatibility with any profile. Its usefulness must be verified against the target and the sample of each journal.

Decision criterion	OJS 3.6 according to public evidence	Jatson according to published information	What remains to be checked
Production source	PKP announces HTML as the production source from the DOCX body.[1][2]	OJS ONE describes a workflow from accepted article, metadata and resources to XML, PDF and HTML.[9]	Whether the results are equivalent on a real sample.
JATS XML	PKP announces a downloadable JATS output; its workflow is not JATS-centered.[1]	OJS ONE states JATS XML production and review.[9]	JATS profile, checks applied and result per target.
SciELO and Redalyc	The PKP announcements reviewed do not establish SPS or a Redalyc workflow.	Jatson's page states preparation for SciELO Chile, not a universal certification.[9]	Collection, validators, package and acceptance by the target.
Metadata correction	PKP notes that OJS and JATS do not update automatically from each other.[1]	There is no measurement published here on how changes propagate.	What will be regenerated and who will approve the final version.

There is also a technical possibility worth testing: using the JATS generated by OJS 3.6 as input for review or enrichment, instead of forcing both processes to compete from the start. The pilot should answer concrete questions: what metadata does OJS keep? What structure or resources need adjustment? Which changes must go back to OJS? Which output does the target finally approve? That possibility is an integration hypothesis, not a capability OJS ONE should promise before implementing and measuring it.

To go deeper into production responsibilities, see the guide on outsourcing JATS XML tagging for SciELO and the article on errors a valid XML can still contain. Both help define evidence, approvals and corrections, but they do not replace testing OJS 3.6.

Mistakes to avoid when evaluating OJS 3.6 JATS XML SciELO

The first mistake is presenting a roadmap as a stable function already operating at the journal. Keep the announcement date, the test version and the version authorized for production separate.

The second is calling any JATS XML "SciELO". Ask for the profile, the collection, the check applied and the result report. The XML structure can be correct and still not meet package or metadata requirements of the target.

The third is reviewing only one output. The XML, HTML, PDF and OJS data must tell the same story after a correction. If they differ, the problem is one of version control, even if each file opens without error.

The fourth is comparing OJS and Jatson only by the number of formats each lists. The useful comparison measures the package that reaches the journal, the corrections needed, the responsibilities and the evidence of conformance the target requires.

Frequently asked questions

Will OJS 3.6 generate JATS XML for SciELO?

PKP announced generation of JATS XML from HTML for OJS 3.6.[1][2] SciELO requires conformance with its Publishing Schema and its own validation checks.[5][6] For that reason, a journal must test the output of the specific OJS version against its collection's requirements before assuming it can deliver it to SciELO.

Can a valid JATS XML be rejected by SciELO or Redalyc?

Yes, because general JATS validity does not show that the file meets a specialized profile, includes the data the target asks for or completes its package and review process. SciELO PS adds rules to the use of JATS, and Marcalyc distinguishes JATS4R outputs from XML for SciELO.[5][7]

Will Jatson replace OJS 3.6's production workflow?

It should not be framed as an automatic replacement. OJS 3.6 may be suitable for certain integrated workflows. Jatson may be relevant when a journal needs specialized production, additional checks or technical preparation that the test has shown to be necessary. The choice depends on the sample articles and the agreed target.

Evaluate the output before changing the process

A journal can prepare the pilot without moving its current production. Define sample articles, the target, acceptance criteria and closing evidence. If you need to review the output workflow or prepare JATS XML, PDF and HTML from accepted articles, learn about OJS One Jatson. The scope must be confirmed according to the journal, the inputs and the technical target required.

Sources

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