JATS — the Journal Article Tag Suite — is a NISO standard (ANSI/NISO Z39.96) that defines an XML vocabulary for scholarly articles: title and authors, affiliations, abstract, sections, figures, tables, math, references, and the rest of the apparatus a research article carries. It is the lingua franca of the publishing back end. PubMed Central (U.S. National Library of Medicine, 2024) ingests and archives articles as JATS; publishers, aggregators, and institutional repositories exchange them as JATS; preservation systems store them as JATS. If your work ends up in any of those places, it ends up as JATS XML.

The crucial thing to understand is what JATS is for. It is an archival and interchange format, not an authoring one. A JATS document is not something a person writes by hand — it is verbose, attribute-heavy XML that a machine emits and another machine reads. It also has no native display: a JATS file needs a stylesheet or a viewer to become a readable page. JATS answers “how do we deposit, exchange, and preserve this article?” — never “how do I write it?”

JATS is also vast. Two decades of refinement have given it well over two hundred elements, many for cases a given article never touches, and it is built for completeness rather than for writing or display. Enscribe does not try to mirror all of it. eHTML — Enscribe’s canonical form — is a small, displayable, authorable HTML vocabulary, on the order of thirty elements covering what most articles actually use, chosen so that what is present translates cleanly outward. That is the trade that makes a direct export possible: a smaller, HTML-shaped vocabulary that maps cleanly to JATS at every point of contact, with the export carrying the translation.

That gap is the whole point of contact with Enscribe. Enscribe is an authoring layer; JATS is a deposit target. The interesting question is how cleanly the one reaches the other.

Enscribe’s canonical form — eHTML, the semantic-HTML representation every Enscribe document compiles to — is deliberately shaped to be JATS-aligned (see the Design article for why). Because the vocabulary was designed against the JATS tag set, the export is mostly a set of one-to-one element renames rather than a lossy transformation. The exporter emits JATS 1.3 Archiving XML, with the correct DOCTYPE and dtd-version="1.3". That correctness is checked, not assumed: the export’s test fixtures are validated against the JATS (and BITS) DTD with xmllint, so the exporter is held to valid JATS — measured against the schema, not merely plausible to the eye.

What maps cleanly — that is, structure-for-structure, no information lost:

The table is a sample, not the full scope: the export also carries links (<a> → <ext-link>), inline <svg> (→ a self-contained <graphic>), and the theorem family, the external-DSL blocks, and code listings.

The one place that maps with a caveat is embedded DSL blocks — Mermaid diagrams, ABC music. JATS has no element for “a Mermaid diagram,” so Enscribe preserves the source rather than inventing a rendering: a <mermaid> block exports as a <fig> carrying a <preformat content-type="mermaid-source"> with the verbatim diagram source and a specific-use="enscribe-dsl-mermaid" marker. Nothing is lost — a downstream consumer that understands the marker can render it — but the diagram travels as source, not as a finished image.¹

Finally, Enscribe draws the same article-versus-book line the standard does. An article exports to JATS 1.3; a book — <meta type=book>, with chapters and parts — exports to BITS 2.0 (U.S. National Library of Medicine, 2016), the Book Interchange Tag Suite, with <book>, <book-meta>, and <book-part> wrappers and the BITS DOCTYPE. Same authoring surface, the correct deposit format for each shape.

Export is the half that lets an Enscribe document reach a journal. The other half is the round trip — write in Enscribe, export to JATS for submission, and import JATS from the published corpus back into Enscribe for re-use, correction, or re-display. Both directions now exist: the enscribe import-jats command brings a JATS article into Enscribe — rendered HTML, or canonical .emd source.

Import is deliberately the weaker direction: JATS’s vocabulary is far larger than eHTML’s, so it is acknowledged-lossy — a one-way conversion that applies necessary simplifications, useful as an on-ramp from the existing literature, not a faithful reconstruction. (The only lossless round trip in Enscribe is between its shorthand and eHTML, which are the same document in two notations.) The importer maps what maps — structure, inline formatting, math, citations, figures, tables, cross-references, footnotes, and the theorem family — preserves reader-facing apparatus such as abstracts, keywords, and acknowledgments, and drops pure publishing metadata, warning about anything it does not recognize.

Import lets a published article — otherwise locked in JATS at a publisher or an archive — be pulled back into editable Enscribe source: to correct an erratum, to re-display it on the open web without a JATS viewer, or to build on it. For a live demonstration, see the demo papers — real published articles from a spread of publishers, converted into Enscribe automatically by enscribe import-jats.

Concrete beats abstract. Here is a short Enscribe fragment:

<meta type=article>
  <title | Calibrating Predicted Probabilities>
  <author | Dana Okonkwo>
</meta>

<# #sec:method | Method #>

We minimise the loss $\mathcal{L}(\theta)$ on a held-out
split.<note | The split is stratified by class.> The procedure
is summarised in <ref @fig:flow>.

<fig #fig:flow src="flow.svg" | The calibration workflow.>

And here is the JATS the exporter produces from it — the <front> generated from <meta>, the body and back from the content:

<article article-type="research-article" xml:lang="en" dtd-version="1.3">
  <front>
    <article-meta>
      <title-group><article-title>Calibrating Predicted Probabilities</article-title></title-group>
      <contrib-group>
        <contrib contrib-type="author"><string-name>Dana Okonkwo</string-name></contrib>
      </contrib-group>
    </article-meta>
  </front>
  <body>
    <sec>
      <title>Method</title>
      <p>We minimise the loss <inline-formula><tex-math><![CDATA[\mathcal{L}(\theta)]]></tex-math></inline-formula>
      on a held-out split.<xref ref-type="fn" rid="note-1">1</xref> The procedure
      is summarised in <xref ref-type="fig" rid="fig:flow">figure 1</xref>.</p>
      <fig id="fig:flow">
        <label>1</label>
        <caption><p>The calibration workflow.</p></caption>
        <graphic xlink:href="flow.svg"/>
      </fig>
    </sec>
  </body>
  <back>
    <fn-group content-type="endnotes">
      <fn id="note-1"><label>1</label><p>The split is stratified by class.</p></fn>
    </fn-group>
  </back>
</article>

Read the two side by side. <meta> became the <front>. The <#> section became a <sec> with a <title>. The inline math became an <inline-formula> carrying the TeX verbatim. The <note> split into two pieces the way JATS expects — an <xref ref-type="fn"> marker where it was written, and the note body collected into a <fn-group> in the <back>. The <ref> resolved to an <xref> that points at the figure and renders as “figure 1”; the figure itself became a <fig> with a <label>, a <caption>, and a <graphic>. Nothing in the source had to know it would become JATS, and nothing in the JATS had to be written by hand.

Most routes to JATS go through a conversion you do not control:

With LaTeX, the structure JATS needs has to be recovered from typesetting commands — a lossy inference, often finished by hand at the publisher. With Word, the document is visually rich but structurally inert, so the conversion is someone else’s interpretation of your formatting.² Enscribe is different in kind: the structure is declared in the source, the canonical form already carries it, and the export is a deterministic rename you run yourself. You see the JATS, you control the JATS, and it is the same every time. Because the mapping is a small, inspectable rename rather than a heuristic, you can predict the output before you run it, diff two exports to see exactly what a source edit changed, and correct a mapping at its source rather than patching XML after the fact. That predictability is the practical difference: an author-controlled export you can reason about, instead of a conversion you submit to and hope for.

Yes. If a venue accepts JATS 1.3 (or BITS 2.0 for books) — and the major archives and a growing list of publishers do — an Enscribe document exports to a valid, structure-faithful deposit, with the apparatus a real article needs intact. And the reverse direction now works too: enscribe import-jats brings published JATS back into Enscribe (lossily, as an on-ramp from the literature). Both halves of the bridge — your work into the scholarly record, and the record back into Enscribe — work today.

For how eHTML is shaped to make this possible, read the Design article; to write your first document, start with the Quickstart.