OJS 3.6 JATS SciELO: What to Check Before Producing

OJS 3.6 JATS SciELO: What to Check Before Producing

OJS 3.6 JATS SciELO is not a decision to switch on an output and stop looking at the file. The version proposed by PKP transforms the submission content into editable HTML and allows JATS to be generated from that HTML; for a journal that works with SciELO, the useful step is to verify the output profile and the package before building it into the editorial cycle.[1]

The right question is not whether a JATS output is enough on its own. It helps to separate three layers: valid JATS XML, conformance with the SciELO Publishing Schema (SciELO PS) and editorial control of the article. Each layer detects different risks and requires different evidence.[2][3]

Original diagram. Each check leaves its own report and its own owner; none replaces the others.

OJS 3.6 JATS SciELO: check the starting HTML

JATS generation in OJS 3.6 relies on a transformation chain, not on an automatic correction of editorial information. PKP describes the step from DOCX to editable HTML of the article body, together with structured metadata stored in OJS. It also says that this conversion produces JATS-compatible HTML, from which the mapping to JATS and its updating are straightforward.[1]

That architecture has a practical consequence: the team should not review only the final XML. It must open the HTML that served as the source, compare it with the approved manuscript and confirm that the elements the journal cares about are expressed unambiguously. A heading with a confusing hierarchy, a misread table or an image without a description can enter the chain before the XML appears.

PKP warns that complex or atypical styles may not transform perfectly, even as the tool keeps improving. For that reason, the first sample should not contain only simple articles. It is better to include a text with sections, quotations, a table, a figure, an equation if the journal publishes them, authors with affiliations and references of different forms. The goal is to learn what the output does with material that represents real editorial practice.[1]

The same source sets an important limit: the JATS-centered workflow, where an external party creates JATS from DOCX and that XML becomes the source for HTML and PDF, is not included in OJS 3.6. That does not prevent using external production; it prevents confusing OJS's HTML workflow with that production scheme.[1]

Distinguish valid JATS XML, SciELO PS and editorial QA

Valid JATS XML answers to a specific JATS grammar. The repository of PKP's JATS Template plugin states that, since OJS 3.6.0.x, the plugin generates valid JATS 1.2 XML. That condition is valuable as proof of structure, but it does not by itself turn the file into a package that fits another exchange profile.[2]

SciELO describes another requirement: the XML it needs must conform to the SciELO Publishing Schema. Its documentation explains that this schema brings together the JATS 1.0 DTD, PMC specifications and the SciELO style; in other words, it specializes aspects of the specification for document submission.[3]

The third layer is editorial. A file can respect a grammar and still contain an incomplete reference, an affiliation assigned to the wrong person, a figure with an insufficient caption or a date that does not match the editorial decision. None of those situations is resolved by looking only at a structural validation message. The review must compare the output with the approved version and with the data the journal decided to publish.

The difference also appears in PKP's own plugin. Its README explains that it delivers a basic template when no higher-quality JATS is available and that it is not intended for publication without improvements and considerable quality control.[2] Read it as a signal of scope: "valid" describes a technical condition; it does not replace a review of content, style or packaging.

Define the output profile before generating the first file

The output profile is the operational specification the journal will set to evaluate each result. Saying "JATS" is not enough. Write down which version, which editorial elements must be present, how identifiers will be represented, what information will be kept for figures and tables, what form references are expected to take and which documents accompany the XML.

This profile must bring together three references: the journal's editorial decisions, the observed behavior of OJS's HTML–JATS transformation and the SciELO PS rules that apply to the package to be prepared. Do not assume that data visible in OJS appears the same in JATS. PKP states explicitly that JATS metadata and the OJS database are not linked; therefore a change in OJS will not be reflected in JATS.[1]

That point deserves version control. Before publishing, note which change was made in OJS, when the output was regenerated and which file was reviewed. If the title, authorship, DOI, a reference or a license field is corrected after JATS is generated, regenerate and compare again. That avoids approving one copy and uploading another.

A short guideline for the output profile may include:

• bibliographic data that must match across OJS, HTML and XML;
• body structure: title, abstract, sections, tables, figures and references;
• handling of affiliations, identifiers and authorship notes;
• elements that require human review depending on the journal's article types;
• output version, reviewer and validation evidence.

Review the package, not just the isolated XML

For SciELO, the practical unit of review is not a loose tag. SciELO's documentation indicates that Package Maker reports possible problems, renames files according to the SciELO PS pattern and separates them into packages. StyleChecker, in turn, delivers a detailed report on an XML's conformance with SciELO PS.[3]

The journal must therefore test the construction of the complete package: file names and locations, XML, graphic assets, tables or supplementary material if applicable, and the consistency of references to those assets. Package review answers questions that an isolated check does not cover: does the XML point to the right resource? Does each name fit the required convention? Does the validation evidence correspond to that same version of the article?

Use SciELO's tools as conformance checks for the profile, not as a declaration of acceptance. Their documentation states that both are used in production and publication according to SciELO PS, and that validation is maintained on every submission even after a vendor certification.[3] For the journal, the operational conclusion is more sober: keep the report, fix what it indicates and run it again on the regenerated package.

Run a test sample with cases that stress the workflow

The test sample must resemble the material that will give the most work, not an ideal article. Choose articles already approved for an internal test, without publishing them through the new workflow until the review is complete. Include a variety of structure, graphic material, authors with several affiliations and references of different types. If the journal uses abstracts in more than one language or supplements, add them to the sample.

The recommended sequence is simple:

1. Define the output profile and a comparison sheet.
2. Generate HTML and JATS from a controlled copy of the article.
3. Review HTML and PDF visually when they are part of the workflow, against the approved editorial document.
4. Validate the XML against the JATS condition the tool declares.
5. Build and review the package with the corresponding SciELO tools.[3]
6. Correct in the right source, regenerate and repeat the checks.
7. Keep the XML, package, reports and editorial decision under an identifiable version.

Do not jump from step 2 to step 5. If the problem originates in the content or in the transformation to HTML, fixing only the XML can create divergences between files. PKP's source presents HTML as the canonical production source for generating outputs; that is a practical reason to first locate where the difference originated.[1]

Organize checks by owner and by moment

Quality improves when each check has a defined owner and moment. The editor validates content, visible metadata, authorship and references against the approved version. The person in charge of production reviews structure, associated files, HTML/PDF output and technical reports. Whoever administers OJS checks that the uploaded version is the approved one and that a later change did not leave the XML out of date.

The technical report does not replace an editorial decision. Editorial review must not hide a packaging problem either. A release checklist should have separate boxes for: editorial match, JATS validity, SciELO PS conformance, package integrity and final uploaded version. When a box fails, the article goes back to the stage that can fix it.

Link this check with your editorial automation guide and with the review of JATS XML errors. They support documenting the internal workflow; they do not replace the evidence of the file and package reviewed.

Common mistakes to avoid

The first mistake is treating "valid JATS" as a synonym for "conformant with SciELO PS". They are related checks, but not equivalent: one looks at the JATS grammar; the other compares the file with SciELO's schema and style.[2][3]

The second is changing metadata in OJS after generating the XML and assuming synchronization. PKP reports that JATS metadata and the OJS database are not linked.[1] The concrete measure is to regenerate, compare and archive the new report.

The third is testing with a single simple manuscript. That result does not show how the chain responds to figures, tables, complex styles or varied references. PKP acknowledges transformation limits for complex or unusual styles.[1]

The fourth is separating technical validation and editorial review as if one were enough. PKP's basic template plugin requires further improvements and quality control before it is fit for publication.[2]

Conclusion: a usable output is shown with evidence

OJS 3.6 opens a path to generate JATS from editable HTML and keep a more integrated file workflow.[1] For a journal that operates with SciELO, the responsible decision is to turn that capability into a controlled test: a written output profile, a representative sample, JATS validation, review against SciELO PS, package verification and editorial control of the released version.[2][3]

The result sought is not a general statement about compatibility or a promise of acceptance. It is repeatable evidence that the journal can review, correct and document each output before using it in production.

Frequently asked questions

Can OJS 3.6 generate JATS XML from HTML?

PKP describes a workflow where the DOCX body is converted into editable, JATS-compatible HTML, with JATS generated from that base.[1] Before relying on that output, test it with representative articles from your journal and review the complete result.

Does valid JATS XML already comply with SciELO PS?

They are not the same check. PKP reports JATS 1.2 validity for its plugin since OJS 3.6.0.x, while SciELO requires conformance with the SciELO Publishing Schema.[2][3] Run the SciELO profile validation and keep its report together with the package.

What should I keep after validating a sample?

Keep the version of the article used, the generated HTML and XML, the package, the tool reports, the editorial checklist and the record of corrections. That evidence shows what was evaluated and lets you repeat the check if content or metadata change.

Specialized production when the workflow needs more control

If your team needs a specialized production layer, Jatson is presented as a complement between the manuscript and publication: it receives the source content, structures it, validates it and converts it into JATS XML, editorial PDF and Scholarly HTML for OJS.[4] It can be an alternative to evaluate when the journal wants to separate specialized production from the everyday administration of OJS. Request an evaluation of the workflow and the package your journal needs, without assuming results before reviewing a sample.

Sources

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