The two-part architecture - Authored without AI

 There is, I suggest, a desirable architectural principle where two kinds of content (data, documentation, or content for publication) need to be kept distinct. On one hand there is content which needs to be formatted in such a way that the format does not change over a long time, or only changes in a highly restricted way. This can be for many reasons, well understood, such as a need to make largely correct assumptions in how it is handled across all downstream processing, reading, consuming, and interpreting. On the other hand there is content outside of such safeguard requirements, which needs less protection from change, might be volatile, might even be experimental, or short-lived. This latter category is manifold and subject to great variation in how, in various ways, it is interpreted. Here the content might need to make assumptions that there exists the other category and that it likely rarely changes, and is unlikely to break these assumptions if they are made in good faith. The second category might assume that it is unknown to those who maintain the first category. We can call these two categories ‘core’ and ‘extensions’, or ‘schema’ and ‘epischemas’ (reference: Gerrit Imsieke, “Epischema – Schema Constraints That Facilitate Content Completion”, XML . com, 29 April 2017) or ‘product’ and ‘product lines’, or ‘cardinal’ and ‘interpretations’. The first category is likely to need long term curation and funding, together with some kind of governance of the whole architecture of the content system. The second is likely to be related in its lifecycle and funding to its context of use. This allows new scenarios and contexts to be accommodated, perhaps experimentally, without so much risk of breaking other content and content in other contexts. It also allows changes over time which might not have been foreseen by the designers and curators in the first category. 

That is the generalisation of the architecture. It can then be applied in various implementations to XML, as also to JSON, or endless other technologies. 

XML has many technologies within its ecosystem which can be used in implementing this kind of architecture, even though this was not the initial intent when this ecosystem was emerging. The initial intent was driven by needs of technology at the time. It centred on concepts such as one schema (or DTD) for each instance, but it eventually supported the aforesaid architecture perhaps because it always had a major goal of extensibility.