US GAAP financial disclosures are articulated in human readable form via the Accounting Standards Codification (ASC)which is published by the FASB.
Each disclosure fits into one of those topics. There could be an exception, but if there is; all one needs to do is create a new topic for the disclosure and add it to that new topic.
Here is a human readable list of disclosures, organized by topic, for commercial and industrial companies which report to the SEC (i.e. I did not include disclosures which relate to specific industries such as depository and lending institutions, brokers and dealers in securities, insurance companies, etc.). This is a machine readable version of the same disclosure information.
Subset of disclosures for testing
US GAAP XBRL Taxonomy (Commercial and insustral companies)
The US GAAP XBRL Taxonomy articulates information about those disclosures. This is a human readable of a subset (commercial and industrial companies) of the US GAAP XBRL Taxonomy information in human readable form. This is a list of all the pieces of that taxonomy. This is ONE of the pieces expressed in machine readable form.
A disclosure prototype is an standard template of a disclosure. The US GAAP XBRL Taxonomy is not expressed in a manner in which disclosures should be expressed. The US GAAP XBRL Taxonomy is more of a "pick list of stuff". You have to figure out how to organize that stuff.
This is a list of prototypes for each of the subset of disclosures I am testing expressed in RSS (both machine readable and readable by humans). This is a list of the same prototypes expressed in machine readable RDF. This an example of ONE prototype. Prototypes exist for each of the 221 disclosures.
A disclosure exemplar is an example of a disclosure from some SEC XBRL financial filing which provided that disclosure. This is a list of sets of exemplars for the 221 disclosures I am testing provided in human readable and machine readable RSS format. Here is that same information provided in machine readable RDF.
This is an example of one set of exemplars for one disclosure provided in machine readable RDF. Sets of exemplars exist for each of the 221 disclosures in the subset I am testing.
Every SEC XBRL financial filing is an exemplar
Every SEC XBRL financial filing is an exemplar. For example, consider this list of the components (pieces) of a financial fling by Microsoft provided by SECXBRL.info. This is the model structure and the fact table of the document and entity information (the first component of the disclosure).
However, you need to figure out if the piece of the SEC XBRL financial filing is a GOOD example or a BAD example. All the exemplars which I selected are good examples. Business rules prove that the examples are good examples.
Business rules are what help external financial reporting managers who create SEC XBRL financial filings correct. While this is not all the business rules needed for each disclosure, it is a human and machine readable RSS list of business rules necessary to make sure the subset of disclosures I am testing are correct. This is ONE such business rules expressed using XBRL definition relations. These business rules exist for each of the disclosures in the subset I am testing.
Testing of representation model and business rules
The exemplars where manually selected by examining countless SEC XBRL finanaical filings. Why do that? It both proves the representation model and the business rules.
Rendering of information
A rendering of the information contained in a financial report is nothing more than a machine taking the model structure, the fact table, an understanding of the different concept arrangement patterns and member arrangement patterns, and an understanding of common approaches to rendering information, and the machine generating the rendering. Some renderings are static such as the SEC XBRL viewer. Other renderings are dynamic, such as the XBRL Cloud Viewer.
Financial Report Ontology (FRO)
The financial report ontology (FRO) contains more metadata and opportunities to create even more metadata by expressing various relations. Sometimes you have to express the relations, other times the relations are already expressed in the ontology. For example, the fundamental accounting concepts metadata is expressed in the financial report ontology. Here are the concepts (human readable | machine readable), here are the mappings to the US GAAP XBRL Taxonomy concepts (human readable | machine readable), here are the impute rules (human and machine readable), here are the relations between the fundamental accounting concepts (human readable | machine readable).
Possibilities if machines could read AND understand this metadata
What if machines could read all of this information? Well, machines can read it. Each set of metadata is machine readable. So reading the information is not the question. Machines understanding the information is what is necessary. THAT is what the financial report disclosure engine is all about.
Ask your software vendor if the software that they provide to you understands this information. Most will say that the applications understand some. But the truth is, it really does not understand the metadata that I have provided here. What some software vendors do is hard code some rules into their software applications. But that means two things: (a) software developers were needed to express the information, (b) software developers are needed to express MORE information.
Business users need to be in control of financial disclosure metadata
Business users need to be in control of financial disclosure metadata. Does that mean they create and edit that metadata using the XML files that I have provided? Certainly not. I have tools for creating that metadata. The tools are relatively easy to use. Unfortunately, the tools are not of commercial quality yet.
Business users use tools to create metadata. Business rules engines, financial disclosure engines, and other "engines" or "processors" work with that metadata to verify the business rules. Can all rules be evaluated this way? I don't know, but I would speculate not. But there are many, many that can.
All of this needs to be unambiguous. Computers cannot deal with ambiguity at all. Sometimes it seems like they can, but that is not what is really going on. What is going on is that someone either made some decision as to how to interpret the situation or someone make some list of things the computer can understand to sort through the ambiguity.
Standards are good
Standards are more efficient and effective ways of working with this metadata. I am trying to get as much as possible into the XBRL format. Not sure how successful I will be. If I am not successful, that means that XBRL is lacking something. No problem, it can be added to XBRL later if enough people feel they need that functionality.