XML in legislature/parliament environments: The fluid nature of work-in-progress legal assets.

Last time in this KLISS series of posts I talked about the critical nature of fidelity with historically produced renderings of legislative artifacts. This time, I want to turn to item 4 in the list of challenges for the XML standard model in legislatures/parliaments : the fluid nature of work-in-progress legal assets.

The process of making law does not begin with a draft bill any more than the making of a song starts with a draft of the lyrics with the melody and the harmonies. The process starts with an idea. Nothing more. Sometimes a well formulated idea. Sometimes it is just a doodle, perhaps with more questions than answers...

This is normally the point at which a law maker engages the help of a specialist drafter. The job of the drafter/drafter/council being to work with the law maker to turn the idea into legal form – to structure it per the rules of the relevant legislature/parliament. From a textual perspective what is happening is that unstructured material is being morphed into structured material.

The process of changing law is quite similar. (Most making of law is, in fact, changing of existing law.) The existing – structured – material is taken as input and various approaches to changing it are likely to be investigated. Maybe section X gets repealed and a new section Y added? Maybe section X is updated on its own. Maybe some of the existing section X text is retained? etc. etc. The skill of the drafter/drafter/council is in knowing all the relevant law and knowing all the possible ways in which the intent of the law maker can be met and knowing the pros/cons of each. From a textual perspective what is happening is that structured material is being rendered temporarily unstructured while various possible implementation approaches are being analyzed. At some point, the un-structured morphs back into structured material again.

Now folks who write software will hopefully have spotted that this process is very much akin to software development. Sometimes you start with nothing but an idea. Sometimes you start with an existing program – a corpus of source code – and an idea. Either way, your act of programming consists of moving from messy unstructured content in your text editor towards very structured content – source code.

I want to tease out that analogy further because it is very much at the heart of how I think about legislative systems. Think about it...what are legal texts really? They are highly formalized, deeply interconnected documents that must obey a rigorous set of rules: rule of syntax, rules of form, rules of idiom, rules of inter-relationship. When there are changes to these documents they are “compiled” together into a new “release” to become the new laws of the land. Sound familiar?

Law is basically source code.

The implications of this – if its true (or can be made true) – are very significant. Not only in terms of the extant Operating System meme but in terms of the topic at hand: the fluid nature of work-in-progress legal assets.

The standard XML model has it that legal documents are structured and therefore they can – and should – have grammars in the form of XML schemas. They should also have author/edit systems that know about the grammars so that users can be helped (or some would argue “forced”) to always keep their documents correctly structured per the schema.

I have two major problems with that model. Firstly, it ignores the fact that most the time – at least in law – changes go through a transitionary author/edit phase when the content is no longer necessarily structured. The author is trying out ideas, moving stuff around. Maybe that heading will be come text in a sub-clause. Maybe this para will bubble up to the long title. Maybe I don't want this (probably structurally invalid) single item bulleted list but I'm going to keep it in the bill until I decide if I want it or not...

I have seen XML editing tools that drive people nuts because they refuse to allow users to move stuff around at will because to do so would cause it to be temporarily broken per XML's rules of structure. But breaking it is part and parcel of the workflow of fixing it back up again after change.

I have seen XML editing tools that refuse to allow users to work on the body of a bill draft until all the required pre-amble material and metadata material is added first. Why? Well, because in the schema, that material is required and it comes before the body of the draft. Well sorry but at the point where I'm trying to create a new draft, I may not know what long title I will want and who the bill sponsors will be or what the chamber of introduction will be... This sort of thing drives many users of classic XML editors in legislatures/parliaments absolutely nuts in my experience.

The second major problem I have with this model is my strongly held opinion that source code and legal code are really the same thing. Let us look at what tools software developers choose for themselves in creating what are very, very structured documents....Do they pick tools that beep when the program is not valid Java syntax? Do they pick tools that refuse to save the source code documents unless they “compile”. Do they pick tools that force the programs to be created from the top down, per the rules of the programming language? Of course not. Instead, they use powerful textual tools that get out of the way. Emacs, vi, TextMate etc. When they do use tools that are aware of the syntax rules: Visual Studio, Netbeans, Eclipse etc. they are all very forgiving of syntax/structure failures. These tools often use a soft form of syntax highlighting to inform users of possible structural problems but they never beep!

If I'm right that source code and law code are more similar that not, why oh why is there such an enormous disparity in the toolsets used by each community? In particular, why have we allowed ourselves to be convinced that rigid inviolate structure rules will work for law (code) when everyone knows that there is no way it would work for source code?

When I am working on source code it is structurally broken. That is either precisely why I am working on it or a necessary stepping stone to me making it structured again after a change. My work-in-progress is very fluid and I use author/edit tools that support that fluidity. I simply would not be able to function if the tools did not allow me to “break” all the rules during the work-in-progress part of my workflow.

When I edit legal and regulatory texts (not as a practicing lawyer, I am not a lawyer – but as a system implementor) I break them in a very similar way. All the time. The notion that all the content needs to obey all the post-production rules during production simply does not ring true for me.

Many of the sucessful systems I have seen in legislative/parliamentary systems have one thing in common - a word processor. In fact, often an old word processor. We are talking DOS and even green-screens here! It is all too common in my experience, for folks to think that legislative systems will automatically be better if those nasty, unstructured word processors are replaced by bright shiny, structured XML editors.

Not so. Not even close. For all their flaws, the word processors worked and they worked for a reason. I'm not saying that legislatures/parliaments should stick with their green-screens and DOS PCs but I am saying that the reasons why the word-processors worked – for all their failings –, need to be properly understood before they are replaced. Thankfully, and this is something I will be returning to later on in this series, we now have generally available tools that allow the benefits of XML to be leveraged without departing from the fluidity of the word-processor form. A form that is, in my opinion, critical to extracting value from law-making IT systems.

Next time, I want to turn to number 5 in my list of concerns about the XML standard model in legislatures/parliaments: the complexity of amendment cycle business rules that often pre-date computers and cannot be changed to make life easier for modern software.