XML in legislature/parliament environments : the complex nature of amendatory actions

Last time in this KLISS series, I talked about the centrality of line/page number citation in amendment cycles and how important it is to treat line/page number artifacts as first class citizens of XML models in legislative/parliamentary environments. I also talked a little about how wonderful the world would be if citations and amendatory workflows were not based on line/page number citations. There are compelling alternatives that have emerged over the last 30-40 years...

However, no other institutions that I know of have workflows that are so influenced by their own history, their own traditions, and most importantly the powerful force of precedent. Some examples from my own experience in this space:

• We do it this way because that approach was established back in Justinian Law times.
  
• We do it this way because the founding fathers did it this way.
  
• We do it this way because we have a law in our statute books that says we do it this way.
  
• We do it this way because chamber rules dictate that we must do it this way.
  
• We do it this way because leadership sees no need to do it any differently. It ain't broken. Why fix it?
  
• We do it this way because we have over 1 thousand person years of experience in our drafting office right now that are based on doing it this way.
  
• We do it this way because hundreds of years of history have evolved it to its current state. It may have its flaws but we know it backwards and have long-established ways of dealing with any problems that occur.
  
• We do it this way because if we changed it, all sorts of things would be impacted down stream in other agencies, third party publishers etc. and it could impact other branches i.e. executive branch, judicial branch.
  

Some other reasons, more subtle, more technological and sometimes contentious, include:

• We do it this way because that is how the mainframe worked back in 1971. We had no ability to do redlining, or printing in color, or spreadsheet calculations back in those days...
  
• We do it this way because we always have. If there is a specific reason, We don't know it is but it might be statutory or in chamber rules somewhere so we don't want to think about changing it. It works. Why risk breaking it?
  
• We do it this way because it has been handed down - quite literally – for generations. It is simply how we do it. Period. We don't change to meet the needs of technology. We expect technology to change to meet our needs.

I will talk more about the alternatives to line/page citation in amendment workflows later in this series of posts. For now, let me just say that Carl Malamud's recent characterization of the law in America as America's Operating System is great and on the right track for sure but I would suggest an addition :

If the law in America is America's operating system then the text of that law – is the source code for that operating system.

(If you re-conceptualize legal texts as source code, a set of amazing things happen...Much more on this later but for now, back to today's topic : the complex nature of amendatory actions.)

Modifications to legal materials : bills, statute etc. are fascinating in many ways. On the face of it, it is just a case of managing a set of “structured” documents, changing them in a controlled way and reporting on the changes. How hard can that be? Sounds like a perfect job for a database of XML documents, doesn't it? Just get some off the shelf XML stuff and bolt it together! Not so fast...let me pick out just three examples and explain why throwing plain old XML tools at the problem of amendatory cycles will not really help:

• A bill (at least in North America) is not a document in the same way that a chapter of a novel is a document. Your average bill “pulls in” other content (for example sections of statute). These pulled in documents then may be modified in their new container. Now you have a composite document that “contains” a modified version of another document. The pull in happened at a point in time and resulted in new content that was correct as of a given point in time. Moreover, said content is then itself amended under very strict change control resulting in a new “version” of the statute, at a new point in time, in this bill container.
  
  This new document, is then itself subject to change through time, via committees, floor actions etc. By the time it gets to enrollment (if it gets that far!), it has a very rich history of time-point derivations and modifications. An n-dimensional graph of content inter-relationships, all richly annotated and all critically dependent on point-in-time views and point-in-time-based modifications.
  
  This new document is used as raw material to derive other documents that go on to have independent lives. For example, committee reports, floor amendments, journals etc. Again, all of which are point-in-time based and all of which are themselves subject to change. Then on top of that, if the bill actually makes it into law, the updated statute sections it contains need to be pulled back out and used to update the existing corpus of law. Then on top of that, you have to deal with the fact that not all the sections will be enacted to law at the same time. Some can have sunrise clauses, sunset clauses. The coming-into-force of some might be dependent on some external event e.g. publication is a register etc. etc.
  
  
• A money bill is, essentially, a large numerical calculation pretending to be a document. Depending on jurisdiction, it might be called an appropriations bill or a finance bill or a budget bill...same concept underneath. Although most money bills do not impact statute, they form an enormous part of what a legislature/parliament actually does. A tremendous amount of work goes into money bills and the amendatory processes take the form of line item modifications (e.g. add $1 million to the funding for X) and formulaic changes (e.g. drop general fund expenditure by 10% across the board.).
  
  
• An amendment list (at least in the British Isles) is not a document in the same way that a chapter of a novel is a document. An amendment list (in America think "committee report") is a document but its purpose in life, is to set out how another document – often a bill – is to be modified. A bill, and a set of amendments to a bill, are two documents yet the relationships between them need to be very carefully managed. If one gets out of synch with the other, bad things happen. Either you have an amendment that does not make sense for a particular cut of the bill or a bill that cannot make sense for a particular proposed amendment
  

In the first example, plain old XML and off-the-shelf XML tools do not get to the heart of the problem because almost all of the work in making this process work is not related to hierarchical structure of the documents themselves (XML's home turf). The hard work is keeping track of, and processing with respect to, the point-in-time transclusions and modifications and feedback loops that are littered throughout this entire amendatory lifecycle problem space.

In the second example, plain old XML and off-the-shelf XML tools do not really help because most folk reading the description of a money bill will find the word “spreadsheet” popping into their heads. I do not disagree. Yet legislatures/parliaments use the same line/page-based citation mechanism to work number-centric money bills that they do to work word-centric bills.

In the third example, plain old XML and off-the-shelf XML tools does not really help because all the work is in managing the relationship between the two documents. The “base document” and the one that describes how the “base document” is to be amended. Our old friend line/page number citation is used extensively here. In some jurisdictions I have worked in, the exact language used to describe proposed amendments changes depending on the point in the workflow where the proposed change occurs, so the amendment list contents is sensitive to not only the exact cut of the bill but exactly where in the business process the amend itself is taking place...Oh, and of course, amendments can themselves be amended...(Are we having fun yet?)

...and that is just 3 examples off the top of my head. I could go on for a long time but there is hopefully no need to labor it. In conclusion:

Legislative amendatory cycles often feature problem areas that XML has no magic dissolution powers over:-

• The time dimension is often critically important and is the basis for many of the critical inter-relationships between legislative artifacts. When referencing a legislative document it is often insufficient to be able to point to what version of a particular document you are interested in. It is often the case that what you really need is a way of referencing the version *of the entire corpus*. (More on that important point later in this series).
  
• Some very important legislative documents – those related to budgets/appropriations – are treated as documents complete with page/line numbers but what they really are ( in modern day terminology) is spreadsheets – not XML's sweet spot.
  
• The pre-eminence of line/page numbers – again not XML's sweet spot – has to be addressed as it is central to the amendment cycle and legislatures are all about that amendment cycle. Pumping out the stuff at the end of Bismark's sausage machine is the easy bit.
  

Now let me end by stressing that all is not doom-and-gloom here! I am just taking the time to lay out the problems as I see them so that my proposed approach for dealing with them in an LEA (Legislative Enterprise Architecture) can be understood with respect to the problems I'm trying to solve.

I'm biting off the part of the problem that is hardest (in my opinion) because it also where the most value can be extracted from an eDemocracy perspective. One of the mantras is KLISS is that anything you can do in the presence of government, you can do in the absence of government, without regard to walls or clocks. If you were to walk into a visitors gallery in a state house or parliament you would have great access to what is going on as it happens. You would be able to see the documents in play, watch the motions as they occur, listen to the debate and read the text of the proposed amendments, watch the votes, watch the testimony as it happens...The goal of LEA (Legislative Enterprise Architecture) is to make this degree of access available without regard to your location. Simply put, the goal is to allow legislatures/parliaments to be as “live” and as “real-time” with their publication of information as they want to be....But I'm getting ahead of myself again. More on that later.

Next up is reason number 3 why the standard XML model is not directly applicable in legislatures/parliaments. Namely, the critical nature of fidelity with historically produced renderings of legislative artifacts.

P.S. If you are unfamiliar with legislative/parliamentary procedure and would like a one-picture overview of what goes on inside one. This picture, based on the US Federal Government workflow is a good example of the genre.