Tuesday, June 08, 2010

XML in legislature/parliament environments: the complexity of amendment cycle business rules

Today in this KLISS series, 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.

The XML standard model has it that many business-rules can be encoded in structure rules so that structure-aware XML editors can make sure that documents are valid per the rules every step of the way. This is problematic in legislatures/parliaments for many reasons. I want to talk a little about two main areas where its a lot more complicated that simply pressing a schema-oriented “validate” button.

  • The contextual complexity of business rules
  • The syntactic complexity of business rules

The contextual complexity of business rules

The validity of a document such as a bill draft cannot, in general, be computed simply by looking at the document itself. There is a large contextual space surrounding the document that strongly influences validity. Some examples (with a somewhat US-centric slant...)

  • The sponsor(s) of the bill must be elected members at the time the draft is made
  • The date of drafting must be after the pre-filing date
  • If the date is after the pre-filing date but before start of session, its not valid unless there is an accompanying pre-filing certificate
  • Any statute pulled in must come first from current year bills if that statute has been modied already this session
  • etc...

How many of those rules are expressible in your XML schemas? Not many. Validity here is all contextual and requires lookups and probing for auxiliary information to compute validity.

The syntactic complexity of business rules

Examples in this category include:
  • If is a resolution, the first word must be “Whereas”
  • All citations must be bluebook compliant
  • New sections must use the phrase “New sec.” followed by an n-space and followed by a number except for the first section which must use “New section.”
  • In journals, the messages must come after the committee referrals, even if they happen before it from a time perspective.
  • All pulled in sections can have an effective date and if specified, it must be a date later than the current date. As well as real dates, the “date” might just say “register” in which case the real date of enactment is that specified in the register.
  • ...

How many of those rules are expressible in your XML schemas? Not many. Validity here is mostly complex lexical/syntactic form checking. In XML vernacular, most of the validity here features #PCDATA constraints not constraints on tags or attributes.

Now granted, once you step outside purely grammar oriented notions of validity, tools like Schematron can help but there is no escaping the fact that most real world validity constraints on legislative/parliamentary documents require the services of a fully Turing complete programming environment which rich access to contextual data sets in order to compute validity.

The XML standard model talks a lot about how great it is to be able to ensure that things nest inside other things as they should per the grammar rules. I'm not saying that this is not useful (at times) but it only gives you coverage of a very small fraction of the validity business rules that you need in legislative informatics. Add on top of that the fact that notions of validity change at pretty much every step of the workflow from bill draft to enrolled bill and you can hopefully see the limitations of the XML standard model.

Now it can be argued that some of the business rules could be simplified and that is doubtless true but in most legislatures, the drafting rules and the procedure rules are the result of decades – sometimes centuries worth – of evolution. Making life easy for back-office computers tends not to feature highly on the wish-lists of legislators. Moreover, politics being politics, activity in the front-office often serves to further complicate the workflows in the back-office.

Some of you may be doubting that the workflow and the validation can be all that complicated really. To get a flavor of the issues involved, I will end with some links to interesting documents that speak to the complexity of validity. Oh, and one final complexity I should mention...all of these rules are of course, subject to change at any time. In fact, most legislatures/parliaments have a procedure in their rules known as “suspend the rules” (Having fun yet?) How will your XML schema handle that? :-)

Finally, finally, for those interested in the implications of a rule-based system in which changing the rules is one of the rules, may be interested in Nomic.

Next up in this KLISS series, the subtle inter-play between legal content and legal content renderings.

No comments: