Way back in 2002, when I first started building an editor for legislation, the problem looked so simple. We figured it was a quick six month project and we would then have a product we could resell to other jurisdictions. I remember when we first made our modest proposal, having it pushed back at us and being told we needed to go and rethink it. California had already learned, the hard way, that the deceptively simple problem of building a legislative editor was actually much more difficult and complex. What I have come to appreciate, over time, is that California’s approach actually makes the problem easier. It’s even harder elsewhere where the drafting rules are less structured and well thought out. I actually lucked out in starting with California, and it still took over three years to get a deployed solution in place – and that was only the beginning.
So what makes building a legislative editor so difficult? First of all, you need to understand what a bill really is. If you’re a software developer, the easiest way to understand it is to think of it as a document to “patch” existing law. Quite confusingly to software types, that process of patching the law results in something called “compiling codes”. So bills are patch documents containing intricate instructions for how to modify the law. What’s so hard about that? Well, for starters, the law has been built up over many decades or centuries and has accumulated all sorts of errors and odd situations that have to be accommodated. How do you correctly refer to something when, quite by accident, two different things have been numbered the same? How do you deal with the situation that arises when the law is defined to change in some complex temporal way? What happens when something is referred to by one number before a particular date, and then by a different number after that date? Quickly all these complexities start accumulating on top of your clean and simple architecture and the hope you’ll ever be able to solve it starts becoming a panic that perhaps you’ve attempted a problem that cannot be solved.
Let’s add another layer of complexity to the problem. The patch documents, which legislative types like to call bills, are also patched – or amended to use the real terminology. So you’ve got to deal with patches of patches. As a bill winds through the process of becoming law, it might be amended many times. Tracking all those amendments is going to be important to a lot of people. Keeping it all straight is crucial to producing an eventual result that patches the law accurately. Those legislative types aren’t very understanding when you get it wrong.
So now that you understand the complexity of the process, lets add some more complexity. Legislative traditions were defined long before there were computers. The procedures were defined for an era where everything was done using pen and paper. Amendments were made using scissors and glue. In fact, scissors and glue were still a part of the amendment process until quite recently in California. Other jurisdiction still have to resort to these procedures even today. Unfortunately, it is simply not possible to replace these outdated traditions with modern computer-based methodologies overnight. Legal traditions evolve on a deliberately conservative path. Good luck trying to throw out the old way just because the new way will be easier for the software. Chances are, you’re going to have to adapt more to the current process than the current process is going to adapt to you.
So what other aspects of legislative bill drafting are complex? I could go on and on about this subject. First of all, you’re not going to be able to convince the government to throw out all the existing laws and start again. You’re just going to have to deal with all the strange ways things were done in the past. If they numbered things with vulgar fractions (i.e. 1/2, 1/3) once-upon-a-time, you’re going to have to deal with that. If they believe that 100.15 reads as “one hundred point fifteen” and comes somewhere between “one hundred point ten” and “one hundred point twenty”, except when it is found between “one hundred point one and one hundred point two”, then you’re going to have to accept that too. Then there is the whole subject of redlining. Don’t be fooled into believing that redlining is the same as track changes in a word processor. It might look the same and be conceptually similar, but chances are there is a lot more hidden meaning in those strikes and inserts than you realize. When you get to the subject of making references or citations, you’ll discover just how much ambiguity there is in the subject. Quite often, a reference to a person is by last name alone. The only way to know which person with that last name is being referred to is to understand the context in terms of location and time. Even then, you might have to deal with ambiguity. When you get to the subject of tables, you’ll want to throw your arms in the air and walk away. Amending tables is an almost intractible problem. If you’re lucky, page and line numbers won’t come up at all. How on earth do you represent page and line numbers in a document that is explicitly designed to not worry about the physical aspects of the published form?
Okay, so you have found your way through all of that and now your editor is ready to go. Whew, that was hard! Oh, but now they want to be able to tear apart and rearrange the document in arbitary ways that make no sense with the XML hierarchy you’ve defined. Of course, you’re expected to be able to piece together the resulting mess to produce a valid document. Well they can’t do that. That’s just the way it is and you’ll tell them that when they tell you they’re not happy with the editor. Alright, that’s not a very good answer. Well, back to the drawing boards on that. Building an editor that both conforms to the software notions of how a document should be structured and how a non-technical users perceives it to be structured is a very difficult problem.
Legislative XML editors can be built. There are a few successful examples to show that it is possible. I’m proud to have muddled through to success with California, but it was very difficult. At the same time, there have been plenty of failures and projects that have gone way over budget. Having a standardized model, such as is promised by Akoma Ntoso and the standards effort within OASIS, should help by allowing this problem to be solved only a few times and then reused many times afterwards. However, given all the variations that exist, even with a standard in place this is going to be a difficult problem to solve for the foreseeable future.
