Talks

True but Irrelevant

TUG 2025 · Thiruvananthapuram, India · July 2025

▶ Watch the talk on YouTube 🎙 Listen to the AI podcast

Key points from this talk

The central distinction

Correct is not the same as useful

This is the root of everything. The field has, over thirty years, invested enormous effort in things that were technically defensible but served no practical purpose. The vision was internally consistent. The effort was genuine. But the outcomes were, in many cases, irrelevant to what actually needed to happen.

On what you choose to capture

True but Irrelevant

The master label. A requirement, a field, a constraint that is technically correct but serves no actual purpose in the system you are building. Before adding anything, ask whether it is needed – not whether it is defensible.

Don't capture what you can't spell

If you are uncertain whether a field is needed, the uncertainty is the answer. The cost of a wrong field is higher than the cost of an absent one. Every field you add that nobody uses still needs to be validated, corrected, explained, and maintained.

Null is an answer

The inability to mark up something that is not there is a design flaw, not a content flaw. Respecting the empty set – knowing when nothing is the right value – is a form of honesty that inline markup has always struggled with.

On what you build for

The article is not the product – the corpus is

Optimising for the individual record while neglecting consistency across millions of them is the original sin of content architecture. A data point that only appears in new articles is not a data point; it is a promise.

The ocean and the waves

The inflow of new content is the waves. The accumulated corpus is four kilometres of water underneath. You cannot navigate the ocean by watching only the surface. Quality improvements only matter when applied consistently across the whole body – not just the waves arriving today.

Build for differences, not for fresh starts

When a revised version of an article arrives, the system should know what changed and recompute only what needs to be recomputed. Most pipelines treat every revision as a new article. They should not.

On how you model things

Model the data, not the words

An affiliation field contains what authors actually wrote – which is often a job title, a street address, or two departments listed together. Build for what the data is, not for what the word means.

A byline is not an author

The string "Pierre and Marie Curie" is perfectly valid content. That your schema expects one author per slot is your problem. Forcing content into a model it does not fit always creates more errors than it prevents.

Write the way you want, annotate with precision

Flexible content and strict annotations are not in conflict – separating them is the whole point. The article text is what it is; the assertions made about it can be as precise as needed, applied from outside, without touching the source.

The sticky note beats the bracket

A standoff annotation – attached from outside the document – can overlap, be added later, be disputed, be retracted, and record that something is not there. An XML tag cannot do any of these things. Real tagging is standoff annotation, not angle brackets.

On validation and responsibility

Validate on departure, ignore on arrival

The producer owns data quality. The receiver picks what they need and ignores the rest. When every receiver re-validates against the full schema, the schema cannot evolve – changing it breaks every downstream system simultaneously. This is why the field has been effectively frozen for twenty years.

DTDs are necessary but never sufficient

A schema can tell you the structure is valid. It cannot tell you that all cross-reference targets have labels, or that the affiliation strings are internally consistent. That "more" should be owned by the producer, not redistributed to every consumer.

Blood tests, not autopsies

Run your checks before dispatch. Know your expected ranges. Flag what falls outside them. Do not wait for something to fail downstream before discovering that the data was wrong at the source.

On assumptions that did not materialise

Articles never appeared in multiple styles

The 1990s vision was that the same content would flow into countless different presentations. It did not happen. The infrastructure built to support re-use was real. The use case was not.

Every journal is special – and that is fine

Standardisation requires that participants accept a common constraint. The mistake was not that journals wanted to be special; it was that the architecture was not designed to accommodate that. The journals were always going to win. The standard should have been designed with that in mind.

On the gap between what you preach and what you practise

Eat your own dog food

If the people who designed a standard cannot use it to write their own documentation, that is not a user problem. The chief content architect of a major publisher wrote his internal newsletters in Word for twenty-nine years – not because he was lazy, but because the tooling for his own standard was never accessible enough to make it worth the effort.

The tooling test

If there is no widely available tool that makes your standard easy to use, the standard is not ready. Correctness without usability is just correctness.