XML in legislature/parliament environments: The critical nature of fidelity with historically produced renderings

Last time, in this KLISS series of posts, I talked about amendatory actions in legislatures/parliaments and how gosh-darned complex they can be unless you properly account for modeling time, numerical data and our old friends line/page numbers in your architecture.

As discussed, none of these three critical items come off-the-shelf in your average XML-bag-o-tricks. They are also not “add-on modules” that you can buy after you have selected an off-the-shelf CMS/DMS. They run too deep in the problem space for that. To be handled properly they need to be at the very heart of eDemocracy system architecture and design.

Anyway, enough on that for now. Today I would like to turn to fourth reason 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.

Lets start by recalling the XML mantra that information and the presentation of that information should be separated. Nice idea. In fact, great idea...but it won't work in legislatures/parliaments. (In fact, there are plenty of situations where it won't work outside of legislatures/parliaments either. See Separating Content from Presentation: Easier Said Than Done

Let us look at a few examples of legal-style content where presentation information is of paramount importance.

Below is a beautiful old table rendering taken from Illustrated judgements





Note how important to understanding the content, the layout is. The vertical alignments. The dot leaders. The integral signs...

Now imagine having this in a legal document. Is it even possible to separate the content from the presentation? I doubt it. Even if it was, would you want to? Imagine rendering this information through a different stylesheet or XML transformation...how much of the original rendering would be lost? Would any of it matter? Does anybody really know? Do you want to take the risk that the interpretation might change as a result of a re-rendering? In law, this is a real problem because ever since the twelve tables we have lived in a world where content and presentation of law are fixed at point of promulgation. Heads of state do not sign ones-and-zeros into law. They sign (almost exclusively) paper into law. Paper is the quintessential example of a rendering that doesn't change once you create it. It is locked down. Put it in a safe in the Secretary of States office for 100 years and as long as your vellum and your non-fugitive inks are good, the rendering will be the same.

That is very important for law. Contrast what happens in a purely digital world in which renderings are created on-the-fly through complex algorithms known as word-processor rendering engines or stylesheets...Will a Wordperfect 5.1 document render in Office 11 exactly the same as it did in Wordperfect 5.1? No. Especially once you get into complex layouts like tables. In fact, even if author/edit vendors did wish to standardize how they lay out text in, say, tables, there are patents held by various parties that actively inhibit it.

Will, say, a FOSI stylesheet in XML authoring tool X produce the same layout in authoring tool Y? No. Not even when they are rendering content to the same XML schemas. Will two XSL:FO implementations generate identical PDFs? No...

I don't know about you but I like my laws locked down! I don't like the idea that the semantics of the law – sometimes terribly intertwingled with its presentation – can change depending on what tool is used to look at it...

Below is a more modern but equally beautiful piece of rendering, this time from a piece of Irish legislation.





As a thought experiment, change the rendering in you head. Change the left indents...How about that solitary paragraph with the word “or” in it. Is its position relative to the rest of the text important to the overall meaning? See the hyphens? They all look like they were added by the rendering don't they? So they are not part of the text of the law itself. What if the split occurred between “self-” and “evident”. Would it be self-evident that the hypen is non-discretionary? Would that hyphen be part of the law or an accident of the rendering? Look at the list ornamentations: alpha, to roman to uppercase roman. Are the list ornaments part of the law? Would you get your stylesheets to generate them or wire the values directly into the text? I like my list ornaments to not move! Pretty much every one of these in a legal context is likely to be a target for a citation. It cannot change!

Finally, an example of a form data pretty much every statute book has in some form. A sentencing table for criminal offenses:


Fancy separating the content from presentation there? If the interpretation of that data is in any way related to its rendering you really, really need to know that you can re-create it exactly.

One final point on this...Imagine you are drafting a new law and it is going to pull-in some existing law in order to modify it. In many jurisidictions, the pull-ed in law needs to look exactly as it did when it became law, maybe decades ago, maybe hundreds of years ago. So now your nice shiny new computer system has to typeset law to look like it was produced by a daisywheel typewriter, or a Linotronic or whatever because that is how it looked when it became law.

I have seen situations where the existing law being amended has contained mistakes in its indentation, its list ornamentation, its hyphenation etc. and yet – because this is law – my new computer systems need to be able to replicate the wrongness correctly. Its the law!

I moan when I hear people say that opening up law making and publishing richly marked up legal material is just a simple matter of standardizing on a XML schema and knocking out a few stylesheets...There is a lot, lot more to it than that.

Next up in this whirlwind tour of fun issues with the XML standard model in legislatures/parliaments:, the fluid nature of work-in-progress legal assets.