Kurt Cagle is the managing editor of XML Today and is a ntributing editor to O’Reilly Media, DevX, and TechNewsWorld.  He is working with Diane Mueller on a general XBRL book for O’Reilly Media to be published in early 2010. Mr. Cagle runs a nsulting firm, Metaphorical Web, dealing with future technology issues, XML, distributed mputing, and the like. He can be reached by email. 

I’ve been working with a fair amount of raw XBRL files recently, both as research for a book and because my interest in the technology mes — not from its use as an acunting format — but because it is an XML format. I suspect, given everything else, that this is a somewhat unusual perspective. An acuntant sees an XBRL "document" as a set of "facts" about a given mpany, and is largely unncerned about the internal representation of the format because, all other things being equal, this representation is simply "de."

An XML programmer, on the other hand, sees the world a little bit differently. Most XML programmers are not domain experts (save in their own domain of working with de). For them, XML is something that can be queried, transformed, refactored, and bound to all kinds of external representations…something that can be served up on the Web and stored within specialized kinds of databases. The specific element names are pretty much unimportant (for the most part); it’s the broader structural characteristics of the XML that they tend to work with most heavily.

Given that perspective, the XML developer’s view of XBRL is, to put it bluntly, rather grim. XBRL was designed deliberately to have as little structure as possible, with most of this structure added in via linked lists. Structure does exist, of urse, but it’s all referential. For instance, XBRL has the notion of a ntext, in which all data items from a given report each have a ntext attribute which points to a rresponding data structure that gives details about the ntext: the reporting period, reporting agency, any specifics about the preparer, and so forth.  Any XML designer would likely fold up all of the key information about that ntext into a ntained element, with an appropriate identifier, and any elements that span ntexts uld then reference the primary ntext as an IDREF.

Similarly, linkbases, one of the central characteristics of XBRL, intermix a huge amount of information that needs to be processed and stored in memory in a far more efficient form, typically one that involves resolving three to four orders of links. Yet for some areas such as labels, the most likely putative cases for having more than one label per schema, localization, is generally better solved by having multiple localization files, each of a different language, with the mappings ntained in a direct one-to-one manner between schema name and label all the terms in that language. When multiple instances do arise, the XML can be modified acrdingly with sendary attributes to discern this information.

The idea in both of these cases is the same. If was to sanction multiple potential aeptable alternate representations of XBRL, each of which uld, with aeptable XSLT transformations, be rectified into the canonical format with no loss of representation, such alternate representations would dramatically rce both the size and the mplexity of XBRL documents from the standpoint of the Web developer. In some cases, especially those involving interbank transfer of information in Europe, the multidimensional nature of linkbases satisfy a very real need for hypercube-oriented processing.  In situations like this, the alternative formats may not be tenable. But in most cases (such as the case of the SEC filing data), the hyperdimensional linkages used by canonical XBRL are overkill, and don’t in fact work terribly well on the Web.

This would have additional implications. Functions, which are currently hideously mplex, would end up being made much simpler in alternative formats, especially if you can bind them to specific representations that would be appropriate to the format at hand. An XQuery representation, for instance, would work especially well for XBRL stored within XML databases. In a similar manner, such an approach uld be used to build JSON representations of data with JavaScript functional layers, something that would go a long way to making XBRL appealing to the Web 2.0 crowd.

The language certainly has most of the mechanisms in place to handle the most mplex use cases, but it needs to be able to scale down in those cases where it has less need for the mplex processing. Without it, others potential standards (such as the US National Information Exchange Model, or NIEM) may render it obsolete quickly. (I plan a discussion of an NIEM-based XBRL for a future post.)

Like many standards, XBRL needs to be gnizant of changing technologies and requirements, or it runs the risk of beming ossified, something which benefits no one in the long run.