We built our first bill drafting system in 2002 for the state of California. It took several years to deploy the first version and substantially longer to get to a feature complete state – actually after 2010 (although the progress was piecemeal). The system took an off-the-shelf XML editor, XMetaL, and adapted it to the drafting requirements of the State of California.
The requirements we were presented with had been very well prepared – and this fact smoothed the design and development of the system. Some of the requirements, as I would only appreciate later, really helped simply the system while others, made it much harder.
In the mid twentieth century, California, and many other U.S. states, underwent a period of legislative reform:
• Compiled codes were established to replace layers upon layers of amended statutes.
• Code sections were required to be relatively simple – short with simple underlying hierarchies
• Bills were constrained to a simple flat series of sections. In some ways, the simplistic underlying hierarchy of bill sections is designed to discourage overuse.
• Bills were constrained to only address a single subject preventing unrelated proposals from being tacked onto bills.
• All amendatory language in bills was required to restate sections to be modified in full. (The cut-and-bite style that is so common elsewhere was outlawed)
• Amending language was formalized
• Redlining was added to show the changes being made to the law and/or (depending on the state) the changes from prior versions of the bill
These changes were made to streamline the legislative process, increase transparency, and prevent much of the gaming of the system that you see in other systems.
These changes also made the eventual computerization of the process that much easier — with one exception. That one exception is redlining. It’s super easy, with no prior experience in legislative redlining, to simply equate it to track changes in a word processor and assume that the base editor will simply provide that capability for free. We did that – assuming XMetaL’s track changes feature was adequate. It took us two years to realize our mistake. It’s only when users started trying to use the system did we really come to appreciate the nuanced differences of legislative redlining from track changes.
Simply put, a word processor’s track changes capability is an audit trail of changes the end user has made to the document. There is little formality to how track changes work and it’s an after-the-fact record of changes that were made. Redlining, while superficially similar, is different – it’s a formal record of changes that were instructed to be made or are being proposed to be made – in some cases to another document. The differences between the informality of an after-the-fact record keeping system and the formality of the legislative process are hard to grasp until you come to the horrible reality that your project is about to fail because you cast aside a key requirement of the system to rely upon built-in functionality.
Our new system, the third generation of LegisPro, goes well beyond anything we were ever able to do with the first generation, based on XMetaL. Indeed, the reason we steered well clear of trying to adapt an off-the-shelf XML editor to the legislative process is because of redlining.
Implementing track changes in a word processor or general purpose XML editor is really hard too – and consequently customizing what the base editor provides is quite near impossible. The problem is that you have to try to adapt a somewhat fragile core feature to work in a way in which it wasn’t designed. XMetaL’s approach to this problem was quite simple – they deliberately made it totally impossible to do any customization. In fact, track changes was completely invisible to the programmer. Imagine our horror when we learned this two years into a project after having just learned that the built in capabilities we were depending on were totally inadequate. In the end we worked with the XMetaL team, at a considerable additional cost to the State of California, to develop some private methods in XMetaL that gave us just barely adequate access to the innards of XMetaL that were otherwise being hidden from the programming APIs. These budget-busting heroics saved the project.
As I mentioned earlier, we’ve made the redlining features of LegisPro a core feature of our offering – going well beyond the simple and inadequate track changes offered by other XML editors. We offer a change set mechanism for grouping changes into sets along with associated metadata. And we offer a much richer and more fluid editing environment for working with redlining. It’s been incredibly difficult to get this right, but I think that in the end, having a system that can do legislative redlining properly is well worth it.
