Over the past few weeks, my posts about the HTML5 editor I have been working on have received a lot of attention. One aspect that I have noticed throughout has been people equating legislative markup to XBRL. In fact, I have taken to explaining Akoma Ntoso as being like XBRL for legislation. That helps people better understand what we are up to.
Or does it? It’s a little misleading to describe a legislative information model as being like XBRL for legislation. The reason is that many of the people interested in the transparency aspects of legislative XML are interested in it precisely because they’re interested in tracking budget appropriations. The assumption being made is that the XML will somehow make it possible to track the money that flows through legislation.
In some respects XML does help track money. Certainly, reporting budgets as XML is a whole lot better than the other approach you often see – tables reported as images. Images are a very effective way to hide appropriations from machine processing. However, that’s less and less of a problem. Nowadays, if you take a look at any budget appropriation embedded within legislation, you’re likely to find the numbers reported in a table. Most likely that table will be in the form of an HTML table at that. How you interpret that table is up to you. Perhaps the CSS class names for each cell will provide some guidance as to each cell’s content, but the information is being reported in a manner intended for human consumption rather than machine processing. In short, the manner in which financial information is reported in legislation is not for the sake of improving the transparency of the data.
In California, when we designed the budget amending facilities within the bill drafting system, our objective was to find a way to draft a budget amendment with the limited tabular capabilities of XMetaL. Whether the result was transparent or not was not a consideration as it was not a requirement six years ago. Victory for us was finding a way to get the immediate job done. Elsewhere, I have yet to see any legislative information model attempt to address the issue of making budget appropriations more transparent. Rather, the focus is instead on things like the temporal aspects of amending the law, the issues that arise in a multilingual society, or ensuring the accuracy and authenticity of the documents.
So what is the solution? I must profess to know very little about XBRL. What I do know tells me that it is not a suitable replacement for all those HTML tables that we tend to use. XBRL is a complex data format normalized for database consumption. The information is not stored in a manner that would allow for easy authoring by a human author or easy reading by a human reader. I did find one article from three years back that begins to address the issue. Certainly we’ve come far on the subject of legislative XML and it’s time to reconsider this subject.
The good news is that we do have a solution for integrating XBRL with legislative XML. Within an Akoma Ntoso document is a proprietary section found inside the metadata block. This section is set aside specifically to allow foreign information models to be embedded within the legislative document. So, much as the metadata already contains analysis sections for recording the temporal aspects of the legislation, it is quite easy to add an XBRL section to record the financial aspects of the legislation.
So the next question is whether or not XBRL is designed to be embedded within another document. It would seem that the answer is yes – and it is called inline XBRL. While the specification addresses fragments of XBRL within HTML documents, I don’t see why this cannot be extended to a legislative information model. Simply put, a fragment of inline XBRL data would be embedded within the metadata block of the legislative document recorded in XML. This data would be available for any XBRL processor to discover (how is another question) and consume. The inline XBRL would be produced prior to publication by analyzing the legislative XML’s tables used to draft the document.
Ideally, the XBRL data would be hooked directly to the legislative XML data, much like spreadsheet formalas can be attached to data, but maybe I’m getting ahead of myself. Providing budget appropriation information within inline XBRL embedded within the legislative XML would be a great step forward – and it would achieve the objectives that people that are interested in the transparency aspects of legislative XML actually have.
I’m certainly no expert in XBRL, so I’m interested in hearing what people in the know have to say about this. Let me know. If you know of an appropriations taxonomy for XBRL, let me know. And if you’re interested in following how the DATA Act might influence this subject, check out the Data Transparency Coalition.
