I built the legislative drafting tool used by the Office of the Legislative Counsel in California. It was a long and arduous process and took several years to complete. Issues like redlining, page & line numbers, and the complexities of tables really turned an effort that, while looking quite simple at the surface, into a very difficult task. We used XMetaL as the base tool and customized it from there, developing what has to be the most sophisticated implementation of XMetaL out there. We even had to have a special API added to XMetaL to allow us to drive the change tracking mechanism to support the very specialized redlining needs one finds in legislation.
Using an XML editor allows one to develop a very precise and accurate solution. The price you pay is the rigidity imposed upon you by the XML structure enforced by the editor. We worked very hard to loosen up that rigidity by providing a rules-based system that allowed the user to work within some wiggle room relying the application to sense what was intended and produce the desired rigid structure that XML demands. Another approach, taken by many, is to use a word processor to generate the document, relying on styles or lightweight tagging in the word processor to guide an XML generator or transformer after-the-fact. This gives the drafter more flexibility, at the expense of the accuracy when the drafter deviates outside of the expected range of document patterns that the XML generator can handle.
I have often wondered if a web-based editor wouldn’t be a better approach, allowing us to achieve the flexibility the user needs with the rigidity that makes XML useful to downstream processing. In the end, the question has always been whether such an editor is even possible. When the Writely word processor (now Google Docs) came along in 2005, the answer seemed to be a tentative yes. Looking into it a little bit I discovered that while feasible, given all the browser incompatibilites of the time, achieving a worthwhile editor of the sophistication needed to draft and manage legislation would still be a daunting task. So the idea has always remained in the back of my mind waiting for browser technology to mature to the point where building such an editor comes within a shot of being a reasonable approach.
That point has now arrived. With HTML5, it is now possible to build a full fledged browser-based legislative editor. For the past few months I have been building a prototype legislative editor in HTML5 that uses Akoma Ntoso as its XML schema. The results have been most gratifying. Certainly, building such an editor is no easy task. Having been working in this subject for 10 years now I have all the issues well internalized and can navigate the difficulties that arise. But I have come a long way towards achieving the holy grail of legislative editors – a web-based, standards-based, browser-neutral solution.
There are a lot of challenges. Interacting with all the browser events to maintain an undo stack is no easy task. Building a change tracking mechanism from scratch gives me lots of freedom but getting your head around all the variations is bewildering at times. And how do you build something that is useful to multiple jurisdictions and is sufficiently flexible to adapt to all the varying needs? This takes a trick – but one I have thought long and hard about.
HTML5 is not yet a fully defined standard. None of the browsers fully support what is defined. The same can be said for CSS, JavaScript, XML Support, and on and on. But the editor I have built works with the latest version of all four major browsers. I don’t have a single CSS quirk at all. In fact, the only substantive browser incompatibility that I have had to deal with arises from the fact that Internet Explorer’s XML implementation pre-dates the standard in this area and the API does not yet match the full standards-based API. This is the case despite IE having been the pioneer in this area.
What’s more, I have achieved this with Akoma Ntoso as the internal XML schema. Akoma Ntoso is itself a proposed standard within OASIS. Certainly not everything has been smooth sailing and I have submitted a whole slew of issues to the drafters of Akoma Ntoso, but I have been able to find my way to a workable implementation. It works!
Our plan is to use this prototype for the Unhackathon at UC Hastings and Stanford Law School on May 19th and then in follow-on events elsewhere. In a few days I will provide a link to the prototype for everyone to try it out. It’s still early days and the editor is far from being a complete and robust tool suitable for production, but what I have now confirms my belief that the next generation of legislative systems will be web-based and built on open-standards.
In my next post I will provide a little mini-tutorial to set the stage for the upcoming pre-beta release.
