Hi @castedo,
OJS/OMP/OPS do not (yet) have a built-in workflow for body text. We have intentionally left that to external typesetting tools. We are beginning to explore the integration of an off-the-shelf HTML editor with mappings to and from JATS, but that work is in early stages.
So when you import JATS to e.g. OJS via some mechanism (see this thread, and I believe the PKP hosting team also maintains one), OJS ingests the metadata, but will only treat the body as a file that it does not interact with (which facilitates the current workflow, whereby users generally work with word processor documents).
Starting with 3.5.0 (when it’s released) OJS will have a “home” for JATS documents to live – see Add basic support for JATS XML files to publications · Issue #7505 · pkp/pkp-lib · GitHub for details.
Typically authors do not arrive with JATS in hand; it’s up to the journal to create it. Most journals that have this requirement will generate JATS by using 3rd-party tools or out-sourcing the creation entirely…
Articles in JATS form are presented to the reader in a variety of ways, such as the JATS Parser Plugin or Lens Galley plugin (sadly Lens Reader is no longer maintained upstream but it is used in production by journals).
A galley is the “reader-ready” form of an article, typically PDF or HTML. It is only available for journal insiders to work with during the article workflow, but when the issue is published, it becomes available to readers.
OJS does not currently support MECA. I’ve been active within the MECA standard-setting group, but that hasn’t yet led to an implementation in OJS; the main impediment is that MECA currently requires FTP accounts for transport, and that’s not going to work for the majority of the OJS user community.
As for the JATS generation side of OJS – that is currently done through the JATS Template plugin, and made available through the OAI JATS plugin.
As you can see, the current landscape is a wide variety of tools that don’t currently cohere into a single toolchain. We have been lacking a free/open source JATS-native web-based editor for the rest of the tools to adhere to, and unfortunately the ones we’ve worked with (Texture and Libero) have both died on the vine. I don’t see a good candidate showing up in the ecosystem in the near term, unfortunately. This is why we’re starting to look at a HTML editor instead, with mappings to and from JATS.
Happy to talk further!
Regards,
Alec Smecher
Public Knowledge Project Team