Why PDF-first goes wrong
In a PDF-first workflow the published article and the structured file are made by different processes, at different times, often by different organisations, from different inputs. They are two descriptions of one article, and nothing keeps them in agreement.
So they diverge, and the divergence is discovered late and in the worst way: an index holds a different author list from the published page, or a correction made at proof exists in the PDF and not in the deposit. Fixing it is not an edit at that point. It is a correction to the record.
The second cost is time. The structured file is downstream of publication, so it is never urgent, so it is late - which means the article is invisible to anything that reads structure for as long as it takes.
What XML-first means in practice
One approved article, written out in as many forms as you need. The editor works on the article's structure and content; the page design, the online version and the deposits are renderings of it.
That has a few consequences worth being concrete about:
- A correction is made once. The galley, the online version and every deposit are produced again from the corrected article, so they cannot disagree.
- The deposit is ready when the article is, because it is not a separate job.
- Checks happen before publication. "This reference has no year" is a question for the editor now, not a rejection notice from a deposit later.
- The journal's design can change without touching any article: it is a specification applied at rendering, not something baked into each file.
- A new output format is a new rendering rather than a re-conversion of the whole archive.
The objection, and it is a fair one
XML-first is usually sold as being better and is usually resisted because it is harder, and the resistance is not unreasonable: it front-loads work. Somebody has to settle the structure of the article before it is published, and that is a step PDF-first does not have.
The honest answer is that the step exists in both workflows. In PDF-first it happens later, at a vendor, performed by somebody who has not read the paper and cannot ask. Moving it earlier does not add work; it moves it to the person who can do it correctly, and makes everything downstream fall out of it.
What it does not require
It does not require anyone in your office to read or write XML. The whole point is that the structure is edited as a document - headings, authors, figures, references - and the file is written out from it.
It also does not require authors to change anything. They submit what they always submitted. The structuring happens after acceptance, which is where it belongs.
How to move a journal to it
Not all at once, and not with the back catalogue. The sequence that works:
- Record one journal's design as a specification, properly, with somebody who knows what the journal should look like.
- Put the next accepted article through end to end and compare the galley with what your typesetter would have produced.
- Run one full issue, including the proofs and the deposits, before changing anything about how the next one is commissioned.
- Only then look at the archive, worst-findable title first.
Last reviewed
