The Promise — and Limits — of XML-First Design
In the early 2000s, technology’s influence across industries became undeniable. Even sectors traditionally slow to change began embracing digital tools as the shift from paper to digital accelerated.
Legislatures were no exception. Drafting attorneys, legislative staff, and administrators began asking how technology could support the complex work of law-making. The goal was clear: reduce inefficiencies while maintaining the precision and integrity that legislation demands.
Consultants were brought in to guide legislatures through digital transformation. Across many of these conversations, one solution surfaced repeatedly: XML.
XML promised a compelling vision. Legislative documents could be structured digitally from the start, making them easier to manage, search, reuse, and publish. In theory, drafting could become more efficient and less error-prone.
XML-centric systems typically require documents to conform to a rigid schema. The structure must be correct from the outset, and the author must follow strict rules governing how content is created.
XML in Practice
In an XML editing environment, every paragraph, indentation level, heading, and structural element must align with the schema. If the structure is wrong, the document may fail validation or render incorrectly.
In practice, this places significant responsibility on the author. Drafting attorneys must think not only about the substance of the law, but also about whether each element is being entered into the system correctly.
The stakes become high: the document must be structurally perfect at the point of entry.
So does this model actually make legislative drafting easier?
Not necessarily.
The Reality of Legislative Workflows: Complexity Beyond Schema
Legislative drafting is not a linear or formulaic process.
Unlike engineers designing a structured system, lawyers develop arguments and iterate through language. Drafts often begin as what one might call a “dog’s breakfast” of ideas, fragments of legal reasoning, partial clauses, and evolving structure.
Lawyers need the freedom to think through the substance of legislation before the structure is finalized.
For example, long legislative texts may begin with an executive summary that ultimately appears at the beginning of the document. But the summary itself is often written only after the rest of the draft is developed.
This iterative process clashes with the rigid input requirements of many XML editing environments.
Increased Cognitive Load when Navigating New Drafting Tools
There is also the issue of cognitive load.
When drafting attorneys must constantly think about the mechanics of the tool — whether an element is the correct tag, whether the structure validates, their brain space is taken away from the legal reasoning itself.
Instead of focusing on questions like:
- Is this provision constitutional?
- Does this clause create ambiguity?
- Will the language hold up in court?
they must think about how the software expects the document to be structured.
That shift breaks the author’s flow.
Lessons from XML-Centric Implementations
Several legislatures experimented with XML-first drafting environments in the early 2000s, often based on specialized editors such as Arbortext or XMetaL.
These implementations revealed important challenges.
Consulting firms had promoted the idea that statutes were inherently structured documents and therefore ideally suited to XML-centric authoring systems. On paper, this logic seemed sound.
In practice, however, many drafting attorneys resisted the approach.
One reason was loss of visual fidelity during drafting.
Legislative documents often rely heavily on formatting conventions. In Commonwealth jurisdictions, for example, indentation levels can affect meaning. If attorneys cannot clearly see how a clause will appear in the final published form, they risk introducing ambiguity.
This led many drafters to prefer a WYSIWYG environment — “what you see is what you get.”
More accurately, what many legislators want is “what you see is what you will publish.”
If the drafting environment closely resembles the final printed legislation, attorneys can reason about structure and meaning simultaneously.
Another issue emerged around duplicated effort.
In some XML-centric workflows, content effectively had to be written twice: once in the drafting environment and again during the preparation of the final legislative publication. This introduced inefficiencies and created opportunities for errors.
The lesson from these implementations was clear: legislative systems must adapt to the way lawyers work, rather than force lawyers to adopt the mindset of structured data engineers.
A More Sustainable Model: Word-Based Authoring with XML Interoperability
Ironically, many of these same XML outputs can be generated from far more familiar authoring environments. For example, Word documents can be converted into XML without requiring the author to work directly within a schema-driven interface.
Instead of requiring drafting attorneys to work directly inside XML editors, systems can provide a familiar environment, like Microsoft Word, combined with guided authoring tools.
In this model:
- Lawyers draft legislation in a visually accurate environment.
- The system provides guidance to ensure structure and validation rules are met.
- Structured XML is generated behind the scenes for downstream systems.
This approach dramatically reduces cognitive load. Attorneys remain focused on legal reasoning while the system handles structural consistency.
Importantly, Word-based environments also benefit from a massive support ecosystem. Unlike niche XML editors with specialized scripting languages, Word-based tools are widely understood and easier to maintain over long government procurement cycles.
Given that most drafting attorneys graduate from law school without experience in XML editors, this approach also reduces training barriers.
Designing for the Future: Output-Centric Architecture
A modern legislative technology stack should focus on outputs and workflows, rather than enforcing structure at the point of authoring.
Each legislature typically has its own validation checks at different stages of drafting, review, amendment, and publication. Systems should support these workflows rather than forcing a single rigid structure.
And in the background, structured data can be maintained about each bill, clause, amendment, and revision.
From this structured foundation, publishing engines can generate output in multiple formats, including XML schemas required by national publication standards.
The Welsh Parliament is one example of this approach. While legislative content ultimately conforms to structured XML schemas for publication, the authoring process is designed to minimize friction for subject-matter experts.
This distinction is crucial.
The people creating legislation are subject-matter experts, not structured data engineers. Their priority is producing accurate, high-quality legal content.
Systems should support them with low-friction, guided authoring experiences, allowing them to focus on substance while the technology ensures structural consistency.
Aligning Technology with Legislative Reality
The vision behind XML-based legislation was not wrong. Structured legislative data offers enormous benefits for publishing, interoperability, and long-term statute management.
But systems that force drafting attorneys to work directly within rigid XML environments often struggle to gain adoption.
Legislative technology must acknowledge a fundamental truth: the drafting process is creative, iterative, and deeply cognitive.
Successful systems reduce friction for authors while preserving structured outputs for downstream use.
In other words, the future of legislative technology lies in author-first design with XML-enabled publishing.