Building a Web-Based Legislative Editor by Grant Vergottini.
From the post:
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.
…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.
Not even out in beta, yet, but a promising report from someone who knows the ends and outs of legislation editors.
Why is that relevant for topic maps?
A web-based editor could, not necessarily will, lead to custom editors that are configured for work flows in the production of topic map work products.
If you think about it, we interact with work flows based on our recognition of subjects and taking actions based on the subjects we recognize.
Not a big step for software to record which subjects we have recognized, while our machinery silently adds identifiers, updates indexes of associations and performs other tasks.
PS: I originally saw this mentioned at the Legal Informatics blog.