![]() ![]() Chances are that API is proprietary and you have no guarantee that they won’t change it on a whim. When you choose to customize an off-the-shelf application, you have to buy into the API that the tool vendor supplies. There is another problem as well with this approach. This is something well beyond the original intent of the word processor and dealing with the mismatch in mission statements for a word processor and a legislative drafting tool leaves open lots of room for issues in the resulting legislation. Another approach is to use a word processor and bend and distort it into being an XML editor. But they’re not the easiest tools to master – for either the developer or the end user. They intrinsically understand XML and are very customizable. Most XML editors are built with this type of customization in mind. So that leaves you with the choice of building your editor atop a customizable XML editor or customizing the heck out of a word processor. That’s a bad idea in this day and age when there are so many existing editors to build upon. First, you can build a full custom editor. Today you have several choices when you build a legislative editor. The editor is built upon open web standards. While not yet a standard, it’s on a standards track at the OASIS Standards Consortium and has the best chance of emerging as the standard for legal documents. The editor I am showing uses Akoma Ntoso for its information model. This makes it possible for an industry of plug-and-play tools to emerge, reducing the cost and risks for everyone. So now we’re moving to a new era, tools based on a common open standard. The cost and risk of this type of development still put the effort out of reach of many smaller legislative bodies. But the XML schemas that everyone used were still largely proprietary and that meant everyone still had to invest millions of dollars in semi-custom tools to produce a workable system. This made it possible to use off-the-shelf editors, repositories, and publishing tools. That last decade was the development of the XML era of legislative tools. That meant that all the data was locked into fully custom tools that were built years ago could only be understood by those systems. The first couple generations of legislative systems were built upon totally proprietary data formats. The editor uses an open standard for storing legislative data. There are three reason I think that this approach to building editors is important: The editor is available to experiment with at site. We will be using this editor at our upcoming International Legislation Unhackathons ( ) this coming weekend. But I do believe in being open and sharing what I am working on. Please keep in mind that this editor is still very much in development – so its not fully functional and bug-free at this point. I’ve just released my mini-tutorial for the HTML5-based XML editor I am developing for drafting legislation (actually it’s best for tagging existing legislation at this point). ![]() More to follow as I get the cycles to refine the capabilities. UPDATE: (May 17, 2012) For all the people that asked for more editing capabilities, I have updated the editor to provide rudimentary cut/copy/paste capabilities via the normal shortcut keys. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |