I’m often asked what XML editor it is built from. The answer is that we built our own. Why? That would seem like madness. Building an editor, any editor, is very difficult. Indeed, I built my first editor way back in 1985 and in the years since I’ve built or customized many editors ranging from schematic editors for PCB and wire harness design, visual language-based editors for designing microchips, as well as a few legislative drafting editors. Of all the editors I’ve built, building LegisPro has been the most challenging.
Before I get too far into this blog, let me first describe what LegisPro is — it is more than just an XML editor. Legispro is Xcential’s solution for legislative drafting. It is a structured document editor along with a services backplane built on a modern web-based technology stack. Included with it is a reference and citation manager called a resolver and an amendment generation engine. You can use it as a web application server accessed via a browser, as a desktop application, or use its components to build you own bespoke editor however you wish.
So why did we build LegisPro from the ground up? Why did we invest 10,000 hours or more of our own R&D money to build an XML editor when so many alternatives exist?
The reason is simple — XML editors are, by and large, still toys. With them you can quickly put together very impressive looking demos, but when you get serious about them you quickly run into their limitations. This has always been the problem with XML editors, but the newer crop of web-based editors are even more limited than their desktop predecessors.
I’ve heard arguments that newer XML editors aren’t toys any more. Well, yes, they have come along way. But, no, they are still toys. I’ve been building legislative editor for almost 17 years now and from where I stand, they’re still awfully limited.
So why is this?
First, structured document editing simply a very difficult subject with numerous layers of complexity involved. Think of the word processor that are part of office productivity suites. They have a single fixed general purpose schema that is quite simplistic compared to the needs of any structured document editor. They offer their features in the context of an unchanging underlying content model. XML editors must offer similar features, but in a way that allows for almost any content model.
Second, XML editors tend to be a jack of all trades, master of none. If there is any use case that they excel at, it’s the DocBook/DITA one — and maybe the recipe books they so often demo. The rule making use case is complex and simply hasn’t been a priority to editor vendors looking to go wide rather than deep in any one niche.
Third, there is a vendor mindset that often comes out when you try to work with the editor suppliers that I find most annoying. Their expectation is that you can design or adapt your use case around the limitations of their products. It’s an easy way to push the responsibility for meeting specific requirements back to the customer. I’ve been in this field long enough to know that doesn’t work. Legislative processes are so entrenched in difficult to change traditions that the sort of adaptations the editor vendors want are simply not practical.
Fourth is the nature of working with XML schemas, like Akoma Ntoso, that are designed to encompass all the needs of adopters around the world — schemas that promote openness and interoperability rather than isolated islands of automation. An editor designed to work with such a schema must provide a lot of infrastructure to allow for the adaptation of the all-encompassing schema to local traditions — restricting the usage in some cases and extending it in others. By and large, XML editors don’t consider this need at all.
So how is LegisPro different? What did our 10,000 hour investment buy us?
LegisPro is designed, first and foremost to be a legislative drafting structured document editor — it is not compromised to the lowest common denominator among a wide range of disparate use cases. LegisPro is designed to work with, and take advantage of Akoma Ntoso (and other similar schemas). LegisPro is complex, but that is because it’s reaching to meet the needs of the problem rather than expecting the problem to adapt to it.
Most XML editors are toys — sometimes better suited to building awesome demos than deployable solutions. That may always be the case — for the editors that can’t specialize in any one area. LegisPro is different — it’s meant to be a legislative drafting editor. It’s meant to work with Akoma Ntoso. It’s meant to go into production.
