Hierarchies
The hierarchy shown below shows how a model structure is ideally organized.
Constraints on the hierarchy
The top-level element is an Abstract that is named after the component. The criteria for the rest of the hierarchy are defined with a structural induction specifying which kind of children is allowed where:
| Kind of report element | Allowed children |
|---|---|
| Abstract | Hypercube (if top-level), Abstract, Concept |
| Hypercube | Dimension, LineItems |
| Dimension | Member |
| Member | Member |
| LineItems | Abstract, Concept |
| Concept | none |
A sample hierarchy
Here is an example of how a model structure typically looks like:
Relationship with XBRL networks (for XBRL-savvy readers)
In the real world, it might happen that the model structure differs a bit from this structure. This is because the underlying standard, XBRL, does not enforce any generic policy on how report elements are glued together.
However, Charles Hoffman, the father of XBRL, advocates a best practice for keeping networks consistent. This best practice is enforced or encouraged by many regulatory authorities.
Concretely, the model structure shown above should correspond to the presentation network, while other networks, especially definition networks that build hypercubes, must be consistent.
In the SEC architecture, this consistency is expressed in form of a table, like so:
| From | To | Presentation network | Definition network |
|---|---|---|---|
| Hypercube | Dimension | parent-child | hypercube-dimension |
| Dimension | Member | parent-child | dimension-domain |
| Member | Member | parent-child | domain-member |
| Hypercube | LineItems | parent-child | all (the other way round) |
| LineItems | Abstract | parent-child | domain-member |
| Abstract | Abstract | parent-child | domain-member |
| Abstract | Concept | parent-child | domain-member |
The explanations shown above rely on this best practice.