It is an interesting pattern: the motivation given for big technology transitions – in scientific publishing and elsewhere – are almost invariably things the current technology can already do.
SGML to XML
In the late 1990s, as Elsevier started its move from print to electronic, we were working with SGML – the standard that XML later replaced. You can still read the detailed documentation of those SGML DTDs in the Tag by Tag documentation. At some point, SGML started to feel old-fashioned, and senior management heard about XML, the answer to all our problems: we had to move to XML. While this move was correct, all the reasons they put forward were things we could already do easily with SGML. Yes, we had to move – but not because of those reasons.
The real reasons? SGML was "dead" in the sense of poor tool support. DSSSL stylesheets were practically unusable. XML, with namespaces, Unicode, and MathML support, promised widespread support in standard software libraries – and has delivered on that promise. Those were the real arguments.
From the old platform to a new data platform
Ask someone to describe why we need a modern data platform, and the reasons given are often already fulfilled by everything we have – existing data stores, message hubs, warehouses, data lakes, etc. The prize is not any of those things. The prize is a fundamentally different data model that can support use cases the old model structurally cannot.
The "digital article"
A similar pattern plays out with the "digital article" – the idea that articles should be richer, more interactive, more structured. Almost all of the hallmarks of the Digital Article that get mentioned are properties of the electronic article that has existed on major publishing platforms for two decades.
Why this matters
In all these cases, the desire for progress is abundantly clear from a technology standpoint, but the business justification is weak. The reasons given are true – but irrelevant. In order to make the next step, it is important to work on the real business justification. That justification can be expressed in terms of genuine customer needs: the things we cannot do with the current content and data that we want to do – things that matter to governments taking policy decisions, to researchers evaluating their fields, to anyone who needs to trust the data.
Without that honest account of what is truly new, each transition becomes a technology refresh that leaves the underlying problems intact.