Beyond XML: Stable Representations and Contextual Interpretations as a General Architectural Pattern
Written by ChatGPT, as prompted by Stephen D Green, June 2026
A discussion that began with COBOL's REDEFINES facility and XML validation architectures ultimately led to a much broader question:
Are XML schemas, epischemas, profiles, and overlays merely special cases of a more general architectural pattern?
The answer may be yes.
In fact, the underlying idea appears repeatedly throughout computing, information systems, standards development, and even society itself.
The pattern can be stated simply:
Stable Representation
+
Context
=
Interpretation
Many technologies that appear unrelated can be understood through this lens.
The Starting Point: COBOL REDEFINES
COBOL's REDEFINES facility allows the same storage area to be interpreted according to different record definitions.
The underlying bytes remain unchanged.
What changes is the interpretation applied to those bytes.
The significance of REDEFINES is not primarily about polymorphism, inheritance, or object-oriented design. It is about separating representation from interpretation.
The representation remains stable.
The interpretation varies according to context.
That distinction turns out to be surprisingly important.
XML and Validation Overlays
The same principle can be observed in XML.
Consider a generic business document:
<BusinessDocument>
<DocumentID>...</DocumentID>
<DocumentDate>...</DocumentDate>
<Sender>...</Sender>
<Receiver>...</Receiver>
<Items>...</Items>
<Total>...</Total>
</BusinessDocument>
The structure remains stable.
Yet different contexts may impose different constraints.
One context may require a UUID identifier.
Another may require a legacy order number.
A third may require a manually entered invoice identifier.
A fourth may impose regulatory requirements.
A fifth may impose trading-partner constraints.
The document itself does not change significantly.
The interpretation changes.
The XML community has developed numerous mechanisms for expressing such interpretations:
- XML Schema
- RELAX NG
- Schematron
- NVDL
- XProc
- xml-model processing instructions
- Genericode
The concept of an epischema, proposed by Gerrit Imsieke, is particularly interesting because it explicitly separates a stable base schema from additional contextual constraints.
The epischema does not replace the base schema.
It overlays it.
The Minimal Viable Product Line Perspective
This observation suggests a broader architectural interpretation.
Instead of thinking in terms of schemas and validation, consider:
Base Schema → Canonical Product
Epischema → Product Line Overlay
The Canonical Product defines the stable shared representation.
The Product Line Overlay defines a particular contextual interpretation.
The Product remains stable.
The Product Lines evolve.
This pattern resembles a Minimal Viable Product Line architecture.
A stable core supports an expanding ecosystem of specializations.
Beyond Documents
At first glance, this appears to be a document-centric idea.
However, the same pattern appears throughout software systems.
Consider a database.
A customer table contains data:
CustomerID
Name
Address
The stored data is the stable representation.
Different users apply different interpretations:
- Sales systems
- Marketing systems
- Compliance systems
- Customer-support systems
- Analytics systems
The underlying representation remains unchanged.
The contextual interpretation varies.
Similarly, consider an API.
The API defines a stable contract.
Different clients impose different assumptions:
- Mobile applications
- Web applications
- Reporting systems
- Integration platforms
- AI agents
The API provider does not redesign the API for every client.
The stable representation supports multiple contextual interpretations.
Programming Languages and Compilers
Programming languages provide another example.
A source file is a representation.
Compilers progressively enrich that representation.
Source Text
↓
Parse Tree
↓
Abstract Syntax Tree
↓
Typed AST
↓
Semantic Model
Each stage adds interpretation.
The source code itself remains unchanged.
The system's understanding of the source becomes increasingly rich.
This resembles an XML document acquiring additional contextual interpretations through validation overlays.
Data Lakes and Schema-on-Read
Modern data architectures often move even further in this direction.
Traditional database systems frequently apply schema at the point of storage.
Data lakes often apply schema at the point of use.
The same data may participate in multiple interpretations depending on who is reading it and why.
This has sometimes been described as "schema-on-read."
Viewed more generally, it is another example of the separation between representation and interpretation.
The representation remains stable.
Interpretation is deferred.
Standards as Stable Assumptions
The pattern extends beyond software.
Consider paper sizes.
A4 paper is not physically invariant.
It can be folded, cut, written on, or destroyed.
Yet society standardizes its dimensions.
The value lies not in immutability but in shared assumptions.
Printers, copiers, filing systems, envelopes, and publishing processes all rely upon those assumptions.
The standard provides a stable reference point around which many independent activities can be coordinated.
The same applies to electrical voltages, shipping containers, internet protocols, character encodings, and countless other standards.
Standardization creates reliable assumptions.
Participants can build systems around them.
Stable Cores and Dynamic Contexts
This suggests a broader architectural principle.
Many successful systems divide responsibilities between:
Stable Core
+
Dynamic Context
The stable core provides continuity.
The dynamic context provides adaptability.
The stable core is governed carefully.
The dynamic context evolves rapidly.
The stable core represents shared infrastructure.
The dynamic context represents local specialization.
This distinction appears repeatedly:
- Standards and profiles
- Platforms and plugins
- APIs and clients
- Databases and views
- Languages and type systems
- Documents and validation overlays
Different technologies implement the pattern differently, but the underlying idea remains the same.
Toward Contextual Interpretation Architectures
Historically, many software architectures attempted to anticipate future needs by encoding them directly into data models, type systems, schemas, and standards.
This often led to complexity and rigidity.
An alternative approach is to invest in a stable, well-governed representation while allowing interpretations to evolve independently.
Under this model, the most valuable asset is not a highly specialized representation but a durable representation capable of supporting many future interpretations.
The architecture becomes:
Stable Representation
↓
Context Selection
↓
Interpretation Overlay
↓
Operational View
Validation becomes only one possible outcome.
The more general goal is contextual interpretation.
AI and the Future
The rise of AI may increase the importance of this pattern.
AI systems are often less interested in raw representations than in contextualized representations.
Different agents may require different interpretations of the same underlying data.
One agent may require an accounting view.
Another may require a logistics view.
A third may require a legal or regulatory view.
The stable representation remains unchanged.
The contextual overlays differ.
As the cost of creating overlays decreases, the value of maintaining a stable, trusted core increases.
This may eventually shift attention away from monolithic schemas and toward architectures centered on governed representations and evolving interpretation layers.
Conclusion
What began as a discussion about COBOL REDEFINES and XML validation turns out to point toward a more general principle.
Many successful systems separate representation from interpretation.
They establish stable shared representations that embody common assumptions.
They then allow contextual overlays, profiles, views, type systems, rules, and interpretations to evolve independently.
XML schemas and epischemas are merely one manifestation of this idea.
Databases, APIs, compilers, standards, platforms, and even social infrastructures exhibit the same pattern.
The common theme is not validation.
It is not typing.
It is not document processing.
It is the creation of stable representations that can support many contextual interpretations over time.
Viewed in this way, the architecture is not fundamentally about XML at all.
It is about how complex systems achieve both stability and adaptability simultaneously.
June 2026
