XML in legislature/parliament environments

Last time I talked about KLISS I said I would talk about some of the reasons why a legislature/parliament is not a happy hunting ground for the blind application of standard IT architecture patterns from the document management/content management/publishing space.

The first, often quite glaring architectural non-sequitur goes like this:

1) legislatures/parliaments are full of very structured documents : bills, resolutions, journals, calendars, statutes, annotations...all have readily apparent structure.

2) XML is all about handling very structured documents.

3) Therefore, classic XML approaches fit legislatures/parliaments.

There are a variety of reasons why this analysis is, in my opinion, wrong but it will take me a number of posts to explain why.

Before I start, let me point out that XML *has* an enormous role to play in legislatures/parliaments but it cannot be simply applied blindly per the standard XML value model without causing significant problems. The 7 main reasons are:

a) the centrality of line/page number citation in amendment cycles

b) the complex nature of amendatory actions

c) the critical nature of fidelity with historically produced renderings

d) the fluid nature of work-in-progress legal assets

e) the complexity of amendment cycle business rules that often pre-date computers and cannot be changed to make life easier for modern software

f) the subtle inter-play between legal content and legal content renderings

g) content aggregation and derived document types

Next up : "the centrality of line/page number citation in amendment cycles"

law.gov goes to Washington

The law.gov initiative has arrived in Washington. Stream of today's meeting at the Committee on House Adminstration is here.

I strongly recommend the law.gov video set now up on Youtube covering the meetings held at a variety of law schools over the last few months. Much fascinating stuff.

KLISS. First things first. What is a legislature/parliament?

I thought I'd start talking about the technical aspects of KLISS at the highest possible level...

Before progress can be made modelling any domain inside a computer system, it is necessary to put a box around the highest possible view of the domain, thereby establishing what is inside the model boundary and what is outside.

At the highest possible level of abstraction, a legislature/parliament is a black box, into which a corpus of law (at some time, T) is injected. The legislature/parliament then acts on that corpus to produce an updated corpus of law at some time T+1.

Thats the highest level model that I have found useful to start discussions of enterprise legislative architectures. Some interesting points about this:

0) The "Corpus of Law" is easier to state than it is to enumerate. It includes the primary law for the legislature/parliament obviously but also, depending on the jurisdiction, secondary forms of law and "softer" forms of regulation such as chamber rules.

1) The "Corpus of Law" subject to modification by the legislature/parliament is smaller than the corpus in force. I.e. federal level laws that bind in various ways, at state level, and yet are not modifiable at state level. Some organizations may adopt rules of order like Rogers or Masons, that are not modifiable directly.

2) Note the feedback loop. The corpus of law at time T is the input to the function (the black box) that produces the law at time T+1, and that then becomes the input for the next legislative act. This feedback loop is the primary source of complexity in legislative informatics.

3) Note the self reference. The corpus often includes laws that specify how laws are made. Those laws are themselves often subject to change inside the black box.

4) In order to qualify as a democratic entity, the transition from Corpus(T) to Corpus(T+1) must be rigorously audit trailed and that audit trail is *itself* an output of the legislature/parliament. I.e. journals, committee reports etc. that expose how Corpus(T) became Corpus(T+1).

5) Note the word "act". Legislatures/parliaments act on a corpus i.e. changes are proposed, debated and potentially implemented. The black box can be thought of as an event driven machine. A machine in which events happen (new bills introduced, amendments proposed, votes taken etc..) and these events cause down-stream events/actions.

6) In order for the audit trail to be comprehensive and accurate it must be able to cite - not just documents like bills, committee meeting minutes etc. - but cite those documents as they looked at arbitrary *points in time*.

Some formalisms I find useful in thinking through this model:
Speech acts provide a nice model for reasoning about actions and reactions, causes and effects inside a legislature.

Rigid designators provide a nice model for reasoning about citations and dealing with the incredibly rich, temporally laced, network graph that legislatures both consume and produce.

Eventual consistency provides a nice model for reasoning about the synchronization of all the disparate views of legislative outputs that must somehow be kept consistent: bill status, agenda minutes etc. etc., each produced in paper, PDF, HTML versions PLUS twitter feeds, rss feeds etc.

Peter Suber's paradox of self amendment is an excellent analysis of the problems inherent in a system that operates under a set of modifiable rules in which modifications to the rules must occur according to the rules set out in the set of modifiable rules :-)

Next time: some thoughts on the main reasons why legislatures/parliaments are very different animals to most process-centric/document-centric/publishing-centric organizations and why, most "classic" design patterns need to be modified if they are to be successful in Legislative Enterprise Architectures.