Bye, bye XBRL technical syntax; hello report level semantics! Well actually, the XBRL technical syntax is not going away, it will just be hidden behind easier to use business report semantics.
Who will be the first software vendor to make the leap?
I created a mapping from the SEC XBRL financial report model to XBRL International's public working draft XBRL Abstract Model 2.0. You can see a PDF of that mapping here.
Mapping from SEC Reporting Model Semantics to XBRL Abstract Model 2.0 Semantics
In that same PDF I also did a mapping from the Financial Report Semantics and Dynamics Theory semantics to XBRL International's XBRL Abstract Model semantics.
Mapping from Financial Report Semantics and Dynamics Theory to XBRL Abstract Model 2.0 Semantics
If you go to section 6 Secondary model - Financial Report Logical Model you will see a UML diagram which maps an SEC Filing to the XBRL Abstract Model 2.0. The diagram is rather rough, but there are some interesting tidbits of information which you may find interesting. I will dig into those later perhaps.
I want to point out a few statements from that XBRL Abstract Model 2.0 public working draft:
- Section 1.3 Model vs. meta-model: "... it is important to understand the distinction between modelling and meta-modelling. Whereas a model is typically a representation of some phenomena in the real world, a meta-model is more concerned about describing and defining the actual modelling framework that is used to construct the model." (So it seems to me that: the XBRL Abstract Model 2.0 is actually a meta-model; the US GAAP Taxonomy is meta-data; SEC XBRL financial filings are the actual models)
- Section 1.3.1 Domain modeling: "However, it is anticipated that instances of this meta-model will eventually be created to communicate how XBRL has been applied in specific projects and taxonomies." (Meaning: people who build XBRL taxonomies need to explain their models by mapping them to this XBRL meta-model.)
- Section 1.4 Layered modeling: "the Primary Layer - captures the pure semantics of XBRL and thus, as much as possible, is independent of the XML syntax" and "For this reason, the reader should be aware that syntactical artefacts of XBRL (such as Contexts, Arcs, and Locators) do not appear in this model as they have been considered to be artefacts of syntax rather than having any semantic significance." (Semantics matters, not syntax)
There is a lot of technical stuff in this document. But, there are some key definitions you should care about. These are the key definitions from the XBRL Abstract Model 2.0.
- Model element: named elements or objects or classes of the meta-model.
- DataPoint: defines a reportable item of business information.
- Aspect: defines an identifying or describing characteristic of a business information item data point.
- AspectValue: defines a specific instance of a value of an Aspect.
- Relationship: defines a logical relationship between pairs of Aspects, AspectValues, DataPoints, Resources, and between Aspect and AspectValue, Aspect or DataPoint and Resources. (They seemed to have left out relationships between Cubes, or the sequence/ordering of Cubes.)
- Manifest: defines what is packaged in the Document. (I don't quite get this, does not seem like 'document' is defined well enough, or it is syntax.)
- Cube: defines a collection of CubeRegions that are associated with specified aspects to report. (Note that I do not believe that they mean "aspect" as defined above when they use "aspects" here. Could be wrong.)
- CubeRegion: defines a cartesian product, or set of Aspects, of enumerable AspectValues (corresponding to XBRL hypercubes after subtraction of negative hypercubes from positive hypercubes). (This is a mouth full. Eyes glazing over. Don't quite get this. It may be an irrelevant technical detail, business users may only need to understand what a Cube is. Frankly, I don't know at this point.)