2.1 Table Models

The definition model is a model of the content of the table linkbase which defines the table(s). It is syntax-independent, retaining the same semantics as the table linkbase, but without syntactical details such as XML or XLink. It is also independent of the instance and its DTS.

The structural model represents the structure of the table, independent of the way it was defined and any details pertaining only to the way it will be rendered. It is not just independent of syntax, but independent of definition; there may be many definition models which resolve to the same structural model given appropriate input. The structural model captures the meaning of the financial table.

The rendering model is a direct representation of the structure and values expressed in the final rendered output. It is essentially the structural model, with all breakdowns projected onto the X, Y or Z axis, populated with values from a fact source (usually an instance), and transformed into the shape required by the output format. The rendering model corresponds directly to the XML format used for the conformance suite control files.

2.2 Processes

Resolution is the process of transforming a definition model into a structural model. The instance's DTS may be required to resolve a definition model to a structural model (for example if the definition model specifies a tree of concepts from a starting point in a network). Resolution does not fully resolve definitions which depend on the instance itself (such as definitions meaning "all concepts appearing in the instance"), as these semantics must be preserved in the structural model.

Rendering is the process of transforming a structural model into a rendering model. It involves projecting all breakdowns onto the X, Y or Z axis, creating table headers using labels defined in the linkbase and populating the table with values from a fact source (usually an instance).

2.3 Other Participants

Other objects which participate in processing the table linkbase include:

• Input linkbase: the input syntax which describes the definition model.
• Discoverable Taxonomy Set (DTS): the taxonomies and other linkbases necessary to resolve the definition model to a structural model. Typically this will be the DTS of the instance to be rendered.
• Instance: acts as a fact source for the renderer to look up facts satisfying a set of constraints when populating the rendering model from the structural model.

3.1 Tables

The structural model consists of trees defining the axes of the table. The nodes in these trees specify constraints (often in terms of aspect values), which the facts to be rendered in cells must satisfy. When the table is used for form entry, facts entered by the user must satisfy the constraints for that cell.

These nodes may be open or closed. A closed node specifies constraints for a single column. An open node "expands" (during rendering) to specify multiple columns. Open nodes are used to indicate a range which depends on the instance data, such as "all periods in the instance".

Each axis in the structural model consists of a series of trees. Each tree defines a logically separate breakdown of the fact space by constraints. Each breakdown contributes a set of constraints for each column. These breakdowns are projected onto the axis by taking the cross-product of these sets of constraints (as described in Section 5.1.2).

3.1.1 Axes with a Single Breakdown Tree

Each path through the breakdown tree from root to leaf defines a set of constraints to be satisfied by all cells in a given column of the table. Each closed leaf node corresponds to exactly one column. Each open leaf node corresponds to an unbounded series of columns. A node in the tree which has descendants will typically correspond to a header cell in the final rendering which spans the header cells corresponding to those descendants.

For constraints defined in terms of aspect values, if conflicting constraints (different aspect values for the same aspect) are present in this path, the aspect value closest to the leaf is used. In Figure 2, the path for the second row includes the values "Trading Activities" and "Basic Sales Revenue" for the concept aspect. Only the latter participates in the set of aspect value constraints which are satisfied by every cell in that row. Contrast this with the first column, which has both aspect values "Widget A" (for the "Product" dimension aspect) and "UK" (for the "Geography" dimension aspect) in the set of aspect value constraints.

Figure 3 illustrates the tree of axis nodes for the X axis of Figure 2:

Figure 3: X Axis Tree

Note the roll-up nodes (indicated in green) in the hierarchy labelled "[Default]", which have the following properties:

• Cells in the row or column will identify facts which are not reported against the specified dimension (and therefore imply the default value).
• It will typically be rendered using spanned cells to form an "L-shaped" arrangement in the header. While this style of rendering may be typical, it is not a requirement.

It is possible to have a roll-up node which does not specify a default value, or a non-roll-up node which does specify a default value, but roll-up and default values are most often used together. See Section 3.1.1.2 for more detail.

Figure 4 illustrates the tree of axis nodes for the Y axis of Figure 2:

Figure 4: Y Axis Tree

Note, the node labelled "[No Constraint]". While this node contributes no constraints itself, it exists to contribute a row to the table (by virtue of the path it contributes to the tree).

Since this node contributes no constraints, the "Trading Activities" aspect value constraint for the concept aspect applies to all cells in the row. In contrast, the other leaf nodes in this example constrain the value of the concept aspect, which will take precedence over the "Trading Activities" aspect value constraints defined by the parent node.

It is worth noting the difference between the trees of a single aspect (in this example, the concept aspect on the Y axis), and trees of multiple aspects (in this example, dimension aspects on the X axis). For trees of a single aspect, the roll-up node will not define an aspect value, since this is already defined by the parent. For trees of multiple aspects, the roll-up node will define an aspect value for the aspects which appear in its siblings.

3.1.1.1 Cells

The structural model contains no data (see Figure 1), but it does define the shape of the cell matrix which will be populated in the rendering model.

A single cell, being at the intersection of a single row, single column and single point on the Z axis, can be associated only with facts which satisfy the constraints of the row, column and point on the Z axis. For data presentation, the constraints for a cell identify the subset of the input facts that should be displayed in the cell. For form entry, the constraints for a cell must be satisfied by any fact entered into the cell.

It is possible for multiple facts to be associated with a given cell. The way this is rendered is implementation defined. For example, if a cell contains multiple facts differing only by language, a rendering implementation may use the locale to select the most appropriate fact.

3.1.1.2 Roll-Up

It is common for financial tables to contain "roll-up" columns or rows; for example, to display aggregate values. In XBRL, such values are commonly reported against the default value for a dimension, e.g. a dimension that breaks down data by geographical region might have a default member of "World".

By way of example, let us assume there is an instance that has the following facts:

Figure 5: Structural Model: Example Facts

Concept	Product	Geography	Channel
Sales	Widget A	UK	B2B
Sales	Widget A	US	B2B
Sales	Widget A	World[Default]	B2B
Sales	Widget A	UK	B2C
Sales	Widget A	US	B2C
Sales	Widget A	ES	B2C
Sales	Widget A	World[Default]	B2C
Sales	Widget A	UK	All[Default]
Sales	Widget A	US	All[Default]
Sales	Widget A	ES	All[Default]
Sales	Widget A	World[Default]	All[Default]
Sales	Widget B	World[Default]	B2B
Sales	Widget B	World[Default]	B2C
Sales	Widget B	World[Default]	All[Default]

It is useful to first consider a simple table without a roll-up column:

Figure 6: Structural Model: Single Dimension (Table)

Figure 7: Structural Model: Single Dimension (X Axis Node Tree)

Cells in the first column have a clear meaning: all facts with "Widget A" reported against the "Product" dimension (regardless of Geography and Channel). This column will include the first 11 facts in Figure 5.

Extending the above example to include a drill-down for the Geography dimension, and a roll-up column:

Figure 8: Structural Model: Dimension Drill-down with Roll-Up Column (Table)

Figure 9: Structural Model: Dimension Drill-down with Roll-Up Column (X Axis Node Tree)

The roll-up column will contain all facts with a value of "Widget A" reported against the "Product" dimension, that are not reported against the "Geography" dimension (i.e. with an inferred value of "World[Default]").

To illustrate this further, consider the following alternative example, where only Widget A has been broken down by geography (since there are no facts reported against the "Geography" dimension for "Widget B"), and the "ES" geography has been omitted from the drill-down despite having facts reported against it:

Figure 10: Structural Model: Dimension Drill-down with Roll-Up Column (Table) - Alternative

Figure 11: Structural Model: Dimension Drill-down with Roll-Up Column (X Axis Node Tree) - Alternative

The first roll-up column has only facts reported for Widget A against the "World" (default) value for geography, and does not include facts for the "ES" geography. The second roll-up column has all facts reported for Widget B regardless of geography.

Extending the example further to include a drill-down for the Channel dimension (to save space and to illustrate that they are interchangeable, the x and y axes have also been swapped):

Figure 12: Structural Model: Two Dimension Drill-down with Roll-Up Rows (Table)

Figure 13: Structural Model: Two Dimension Drill-down with Roll-Up Rows (Y Axis Node Tree)

There are now eight roll-up rows (three of which are shown in the tree). The first row matches all facts with "Widget A" reported against the "Product" dimension, "ES" reported against the Geography dimension and not reported against the Channel dimension.

3.2 Table Sets

As defined in Section 3.1, the structural model defines fixed axes for a given table. It is desirable to be able to define a series of tables with a single definition, even where the shape of each table depends on the position in the series.

A table set indicates a sequence of closely related tables with a common definition. For example, it is possible for a single definition to resolve to a different table for each extended link role (ELR):

These two tables form a single table set despite having a different Y axis, since they result from the same definition.

4.1 Definition Nodes

Axes are defined by trees of definition nodes. An definition node may expand to several nodes in the structural model.

4.1.1 Types of Definition Node

Figure 16 shows the types of definition node defined by the table linkbase specification and their relationships to each other.

Figure 16: Types of definition node

4.1.1.1 Rule Node

Rule nodes express their constraints in terms of aspect rules, in the sense defined by the formula specification [FORMULA]. An aspect rule constrains the value of a certain aspect to a specific value. A single rule node addresses zero or more aspects, and specifies exactly one value for each aspect addressed.

A rule node defines a single node in the structural model. Child nodes are defined explicitly by child definition nodes. A rule node may be abstract; non-abstract rule nodes contribute an additional child in the form of a "roll-up" node, as described in Section 3.1.1.2.

4.1.1.2 Relationship Node

Relationship nodes cover a single aspect and use networks defined in a DTS to discover values for the aspect and arrange them for display. Two types of relationship node are defined:

• Concept-relationship nodes cover the concept aspect. A typical use for such a node would be to arrange concepts hierarchically according to the logical structure defined in the presentation network.
• Dimension-relationship nodes cover a specified explicit dimension aspect. They can be used to arrange the members of a dimension according to the hierarchy of domains defined in a dimensional relationship set (DRS).

A relationship node defines an entire tree of nodes in the structural model. Each concept or domain member contributes at least one node to the structural model. Abstract concepts and domain members that are unusable contribute only a single (branch) node, which acts as a parent for their children. Non-abstract concepts and usable dimension members contribute an additional, roll-up node, thus reserving a row/column in the rendered table.

Relationship nodes can be customised by specifying the network to traverse, a starting resource (concept, dimension or dimension member), and details of how to traverse the network.

4.1.1.3 Selection Node

Selection nodes use expressions to generate a sequence of values and bind it to a named variable, which can be referenced by other definition nodes. Each value in the sequence results in a node in the structural model. The values generated by a selection node may be constraints on a specified aspect, or they may be other arbitrary values (for example, link roles).

4.1.1.4 Filter Node

Filter nodes use filters, as defined by the formula specification [FORMULA], to filter facts. The set of aspects covered by a filter node is the union of the aspects covered by its filters. Unlike rule nodes, filter nodes do not require the values of the aspects being covered to be known in advance. A filter node can be used to e.g. breakdown facts by the members of a dimension actually in use in an instance.

4.2 Resolution

Resolution is the process of transforming the definition model into a structural model for the table. This will generally require the DTS of the instance (either an existing instance or, if the table is to be used for data input, the DTS of the target instance). It does not, however, require knowledge of the instance itself.

As described in Section 4.1.1.2, the process of resolving the definition model involves expanding some types of definition node (e.g. relationship nodes) into a tree of structural nodes. At this point, it is necessary to reference the DTS of the instance. The DTS is also necessary to identify concepts, dimensions and explicit dimension members, which are defined in the taxonomy.

4.2.2 Table Sets

In some circumstances, a single table definition can resolve to a set of related tables which have different shapes, even though they share a common definition. A common case is where an axis is defined that covers different extended link roles (ELRs) and the link role is then used to identify the network to be followed by a relationship axis. Networks with different ELRs may describe a completely different hierarchy of concepts, with some concepts appearing in only one network and others appearing in several, possibly under different parents. For example, the single table definition shown in Figure 17 results in the two tables in Figure 14.

Figure 17: Definition model for the tableset in Figure 14

5.1 Rendering

Rendering is the process of transforming the structural model into a rendering model. The process can be divided into four steps:

• expanding open nodes
• projecting breakdowns onto axes
• constructing the table axis headers
• populating the table cells

5.1.2 Projection of Breakdown Trees Onto an Axis

The breakdowns in the structural model are projected onto the axes of the table, resulting in a single axis header in the rendering model for each axis.

A single axis may be composed of multiple breakdown trees. Where this is the case, the cross-product of the constraint sets defined by the trees is taken, which yields a single constraint set for each column:

Figure 21: Rendering Model: Breakdown Tree Projection

The tree resulting from this cross-product is not part of any model, but it is a logical step in producing the rendering model from the structural model.

Figure 22: Rendering Model: Breakdown Tree Projection (Resulting Table)

5.1.3 Constructing Headers

The table axis header corresponding to a tree of nodes can be constructed by creating a row in the header for each level in the tree. Each row in the header should contain a header cell for each closed node, and a number of header cells for each open node.

For example, the tree shown in Figure 22 results in the rendering model in Figure 23:

Figure 23: Rendering Model Headers

The header cells in the rendering model corresponding to a node in the structural model are labelled according to the labels or messages associated with the node.

6.1 Simple Example

Figure 24 gives an example of a simple table in which concepts are displayed in a tree on the y-axis (rows) and the x-axis (columns) breaks down the reported facts by dimension. In this case, facts are initially broken down by the Product dimension; data for Widget A is further broken down by the Geography dimension (perhaps because only Widget A is sold in multiple regions), with a roll-up column to display the total for all regions.

As shown in Figure 25, the x-axis is defined in terms of rules that explicitly select values for each dimension. Each rule node defines a single node in the structural model (with the exception of the root definition, which exists only as a container). An implicit roll-up node is required as a child of the node 'Product = Widget B', to balance the tree and reserve a column in the rendered table.

The definition of the y-axis is very simple, consisting of a single definition node (see Figure 26). This is possible because the concept-relationship node instructs the processor to use a network defined in the DTS to discover concepts and arrange them on the axis. In this case, a network with a link role of 'Statement of Operations' is used; the starting concept, 'Line Items', is not itself included in the structural model, but this behaviour is configurable). An arcrole, not shown here, is also necessary to fully determine the network.

6.2 Example using Multiple Breakdowns

This example extends the simple example in Section 6.1. Figure 27 shows a table in which the y-axis is defined as in the previous example (see Figure 26), but the x-axis breaks down the data by every combination of the Period and Geography dimension. This can be thought of as two separate breakdowns, combined by taking their cross-product.

Figure 28 shows the definition and structural models for the x-axis of the table in Figure 24. The axis is defined in terms of two separate breakdown trees; the first selects two periods from the instance, while the second defines explicit values for the Geography dimension. In the rendered table, the two breakdowns are combined in a cross-product.

Note that the entire x-axis could have been defined using a single tree containing only rules, as in the previous example. Using separate breakdowns allows a more concise definition, while embodying the semantics of breaking down the data by two independent variables. A tool may use this information to allow the user to 'pivot' the different breakdowns; for example, in some situations, it might make more sense to break down the data primarily by the Geography dimension, with Period forming a secondary breakdown, as shown in Figure 29.

6.3 Example of a Table Set

This example extends the example in Section 6.2 by using a single table definition to create a set of related tables. Each table shown in Figure 30 corresponds to a different link role. The x-axis is defined as in the previous example (see Figure 28).

Figure 31 shows the definition and the structural models for the z-axis of the table in Figure 30. In this example, the z-axis is used as a discriminator; different positions along the axis are rendered as separate, 2-D tables. Link roles are selected from the taxonomy and bound in turn to the $linkrole variable, which then determines which network is used to populate the y-axis with concepts (see below).

Figure 32 shows the definition and structural models for the y-axis of the table in Figure 30. Although the y-axis has a different shape for each table, all the tables share a single definition. Different structural models result from traversing different networks of concepts, according to the link role set by the z-axis.