Copyright © 2011, 2012, 2013 XBRL International Inc., All Rights Reserved.
Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to firstname.lastname@example.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This document specifies semantics and syntax constraints for tables. Tables define subsets of the facts and fact related information, defined by a DTS, and specify representation of those facts in a Cartesian coordinate system.
1 Jon Siddle:
The ordering of this expansion needs to be defined by this
specification. We discussed (at the Oxford F2F) using a simple
default sort order provided such an ordering was well-defined
in existing specs (xsd, xpath2, xslt). It appears that no such
ordering exists. This is still an open issue.
We did agree that a tool can always provide alternative (and
interactive) sorting (e.g. on locale-dependent labels), but
must support the default sort.
2 Herm Fischer:Should it be an error if a concept or dimension member qname is not recognized? We're already testing for bad dimension QName (xbrlfe:badUsageOfExplicitDimensionRule).
3 Roland Hommes:An XPath expression on an instance that does not exists will result in a high level XPath error message.
4 Herm Fischer:No XPath-level error, the XPath expression only produces a QName, but the QName has no requirement in XPath to correspond to an existing schema element or anything else. If the rule were to specify a dimension member not existing, in financial filings with extensions, it would probably be necessary to not worry if the extension did not have some dimension that was QNamed.
5 Victor Morilla:This paragraph should be replaced by a reference to section 3.2.7
6 Jon Siddle:This needs clarifying
7 Jon Siddle:I think "in the value of the axis element" would be clearer
8 Roland Hommes:What does it mean when table:generations is both optional and must be ignored?
9 Herm Fischer:It means if you ask for 2 generations of child, parent, or sibling you still only get 1 generation, corresponds to the xfi:concept-relationships. Maybe less convoluted to say generations is optional and only processed for descendant and ancestor axes, otherwise ignored?
10 Jon Siddle:I think it should be an error if generation is present and not 1 for these axes
11 Victor Morilla:The arc role attribute should be common to relationship nodes. We are forcing users to use domain-member relationships for presentation purposes in dimensions. This is not a good practice.
12 Roland Hommes:Errorcode if table:dimension refers to a QName that is not a dimension concept?
13 Herm Fischer:Error could correspond to xfie:invalidDimensionQName in formula functions, but this may be restrictive on financial reporting with extensions, where the dimensions and even their names may be unknown to the table linkbase author.
14 Victor Morilla:This chapter has become obsolete with the introduction of chapter 7
15 Jon Siddle:I don't think it hurts to have an explicit description of the model, even if most of the interesting stuff is described with the process.
16 Jon Siddle:Needs specification
17 Jon Siddle:I believe this section is correct and reasonably precise. The complexity of the description far outweighs the complexity of what it is describing (they're just nested arrays). It needs some diagrams to make this simpler to understand. I'd also like to avoid using the term "dimension" here, but that's probably unavoidable.
18 Herm Fischer:I think this is the wrong term and should be replaced with the notion of binding (as in formula variables), for next edit pass. Then there is a lot under processing that will use this term (as with formula binding and processing).
19 Jon Siddle:I'm not happy with this word, but "expansion" is already taken. On the plus side, partitioning implies you're splitting something that exists (which is accurate since we're operating on facts at this point).
1.1 Relationship to other work
1.2 Namespaces and namespace prefixes
1.3 Document conventions (non-normative)
1.4 XPath usage
3.1 Structural model
3.1.2 Table sets
188.8.131.52 Breakdown labels
184.108.40.206 Uniform depth
220.127.116.11 Aspect Constraints
18.104.22.168 Closed breakdowns
22.214.171.124 Open breakdowns
3.1.5 Structural nodes
126.96.36.199 Closed structural nodes
188.8.131.52 Open structural nodes
184.108.40.206 Roll-up nodes
220.127.116.11 Structural node labels
3.1.6 Unspecified Aspects
3.2 Definition model
18.104.22.168 Aspect model of the table
22.214.171.124 Table sets
3.2.2 Table filters
126.96.36.199 Table-filter relationships
188.8.131.52 Table-breakdown relationships
3.2.5 Definition nodes
184.108.40.206 Closed definition node
220.127.116.11.1 Definition-node-subtree relationships
18.104.22.168.2 Parent-child ordering
22.214.171.124 Open definition node
126.96.36.199 Breakdown-tree relationships
3.2.6 Definition nodes (concrete)
188.8.131.52 Rule node
184.108.40.206.1 Rule node aspect rules
220.127.116.11.2 Rule node syntax
18.104.22.168.3 Rule node resolution
22.214.171.124.4 Rule node labels
126.96.36.199 Relationship nodes
188.8.131.52.1 Relationship binding
184.108.40.206.2 Relationship source
220.127.116.11.3 Relationship node syntax
18.104.22.168.4 Concept-relationship node
22.214.171.124.5 Dimension-relationship node
126.96.36.199 Aspect node
188.8.131.52.1 Aspect node aspect constraints
184.108.40.206.3 Aspect node labels
220.127.116.11.4 Aspect node syntax
18.104.22.168.4.1 Aspect-node-filter relationships
22.214.171.124.4.1.1 Aspect-node-filter arcs
3.2.7 Variable references
3.3 Layout model
3.3.1 Layout tables
3.3.3 Axis headers
3.3.4 Header cell labels
4 Table source
5.1 Structural infoset
5.2 Layout infoset
5.2.1 Table sets
5.2.3 Axis headers
5.2.4 Table cells
6 Processing model (definition of functions)
6.2.1 Table set resolution
6.2.2 Table resolution
126.96.36.199 Height Balancing
6.3.1 Under-specified tables
188.8.131.52 Dimensional Aspects
184.108.40.206 Non-Dimensional Aspects
220.127.116.11 Multiple Values in a Cell
6.3.2 Projection of multiple breakdowns onto an axis
6.3.6 Layout for data presentation
6.3.7 Layout for data entry
A Normative schemas
A.1 Table linkbase schema (table.xsd)
A.2 Layout infoset schema (tablemodel.xsd)
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document
1 Structural model
2 Structural model example table
3 Structural model example
4 Definition model
5 Closed definition node model
6 Rule node model
7 Resolution of an abstract rule node
8 Resolution of a non-abstract rule node
9 Relationship node model
10 Aspect node model
11 Projection of two breakdowns onto an axis
12 Projection involving a more complicated breakdown
closed definition node
closed structural node
complemented aspect-node-filter relationship
concept relationship node
dimension relationship node
domain of a table
fact belonging to a table
open definition node
open structural node
open table definition
participating in a table
rule node label
shape of a table
This document specifies semantics and syntax constraints for tables. Tables define subsets of the facts and fact related information, defined by a DTS, and specify representation of those facts in a Cartesian coordinate system. Facts may already exist, as in rendering an instance document, or be a virtual space in which they can be entered (possibly as editable cells in tables). They may be represented or edited by their value or any other aspect or property (period date, accuracy, footnote, or something deep in a typed dimension).
All tables defined by this specification can be used for rendering existing instances, and some may be used for the addition or modification of facts into new instances.
Tables can be used alone, by tools and consuming applications, or as part of containers in XBRL documents that generate complete reports.
Features of this specification that are used to define the table linkbase are defined abstractly and given concrete realization in syntax, in a manner that provides a base for extension specifications.
Tables specify semantics and syntax of hierarchical representations of facts that instantiate the concepts in XBRL taxonomies. These hierarchies are one of the basic building blocks of the specification, but also constitute by themselves a vehicle to communicate the meaning of those reporting concepts in a similar approach to that of the presentation linkbase, but enhanced to cover multidimensional information and more complex models.
This specification provides a means to associate data with axis positions for rendering in a manner independent of presentation formatting. Issues of font select, color, background, component assembly into documents, are left for the XBRL Rendering Specification.
Namespace prefixes [XML NAMES] will be used
for elements and attributes in
ns is the
namespace prefix and
name is the local name.
Throughout this specification, the mappings
from namespace prefixes to actual namespaces are consistent
with Table 1.
The prefix column in Table 1 is non normative. The namespace URI column is normative.
The XPath expressions allowed by this specification are evaluated with no context item to avoid the use of arbitrary XPath expressions which rely heavily on the XML of the instance.
While this specification does not dictate how it may be used, it does define two main types of use:
Three models are defined by this specification:
The structural model describes a collection of one or more tables defined in a single linkbase, in a way that is independent of the way they were defined.
Figure 1 shows the classes that participate in the structural model.
A table consists of one or more independent breakdowns of the fact space. Together, these constrain the facts to be presented or entered into the table and describe their arrangement in the layout table.
The set of aspects participating in a table is the union of the sets of participating aspects in each of the breakdowns for the table.
The participating aspects for a table MUST include the concept aspect.
The restricted fact space defined by the combination of the constraints from all of a table's breakdowns, along with any additional global constraints specified using table filters, is referred to as the domain of the table.
The domain of the table determines which facts are presented in the table. The facts populating the table may be a subset of the facts in an existing XBRL instance or other fact source, or they may be new facts created from values entered by the user.
Tables may have a fixed shape, independent of the facts to be presented. Alternatively, regions of a table may have shapes that vary depending on the facts being presented.
A closed table is defined as a table that consists only of closed breakdowns.
An open table is defined as a table whose constituent breakdowns include at least one open breakdown.
Any axis without any breakdowns has a single slice (e.g. a row or column) along that axis, which contributes no constraints. For example, a table with only a single breakdown on the x-axis will have one row, and a table with only a single breakdown on the y-axis will have one column.
A table set is a set of one or more tables that share a common definition.
A table definition model may resolve to a series of tables in the structural model. The tables in a table set vary according to the values assigned to the parameters associated with the table definition. Parameter variables may be referenced by definition nodes which affect the shape of the resulting table, such as providing the link role to use in a concept relationship node.
A constraint is satisfied by a fact if the aspect value of the constraint is equivalent to the aspect value of the fact for the corresponding aspect.
Facts must satisfy all of the combined constraints of the intersecting rows and columns to be rendered or entered in a cell.
Closed nodes have constraints which restrict an aspect to exactly one aspect value. For example, a closed node may restrict the "Geography" dimension to a single country. There are constructs in the definition model that allow many closed nodes to be defined using a single definition node. For example, it is possible to define a tree of closed nodes, each restricting the "concept" aspect to a different concept, by reference to a presentation network.
Open nodes have constraints which identify a single aspect to be constrained, but the aspect values are not known until layout is performed, and these may be dependent on the facts present.
A breakdown defines a logically distinct breakdown of the fact space by sets of constraints.
A breakdown is modelled as an ordered tree of structural nodes, each of
which contributes one or more constraints to the breakdown. Each
leaf node corresponds to a row (or column) in the table and each
path through the breakdown tree from root to leaf defines the set of
constraints to be satisfied by facts in the corresponding
row (or column). Figure 2
illustrates a simple table, in which sales figures (y-axis)
are broken down by two dimensions:
Geography (x-axis). Figure 3 shows (part of) the corresponding
structural model (the constraints associated with each node are not
A breakdown may have associated labels. Each of these labels applies to the breakdown as a whole.
All leaf nodes in a breakdown are at the same level in the tree. A path from the root node to any leaf node will therefore have the same length. This property is referred to as uniform depth, and is ensured by height-balancing.
For example, in Figure 3 an
additional roll-up node is needed as a child of
widgetB. This additional node explicitly indicates
that the facts in the corresponding column are not further broken
down at the next level.
Where different aspect values for the same aspect are present in this path, the aspect value closest to the leaf is used.
The aspects participating in a breakdown are the participating aspects of the structural nodes in the breakdown.
Each aspect participating in a breakdown is constrained even if its values are not. In other words, constraining an aspect does not necessarily mean restricting its range of values (although it often does). For example, to produce a column for each period, the period aspect must participate in a breakdown definition. In this case, the period aspect is constrained to all possible period values.
The aspects participating in a breakdown MUST be consistent with the aspect model of the table.
Error code xbrlte:aspectModelMismatch MUST be thrown if the processing software encounters aspects in the structural model that are not defined in the aspect model of the table (as described by Section 18.104.22.168).
Each leaf node in a breakdown has an associated aspect value for all aspects in that breakdown. For a given aspect, the leaf node itself or one of its ancestors may explicitly define a value for that aspect. Where neither the leaf node itself nor any ancestor explicitly specifies an aspect value for some aspect participating elsewhere in the same breakdown, the following rules apply:
For example, the two nodes in Figure 3 with
true constrain the
Geography dimension to its default value.
Error code xbrlte:missingAspectValue MUST be thrown if the processing software encounters a leaf node in a breakdown which does not specify or inherit a value for any non-dimensional aspect which participates elsewhere in that breakdown.
Breakdowns are combined by taking the Cartesian product of the individual lists of constraints. A table MUST NOT contain more than one breakdown that addresses the same aspect (as taking the Cartesian product of the constraints for such breakdowns would be meaningless).
For a single breakdown in isolation, the leaf nodes of the breakdown tree each correspond to a single slice (e.g. a row or column) in the layout table. Branch nodes correspond to headers in the layout table that span the headers corresponding to the descendant nodes.
The aspects participating in a breakdown can always be determined during the resolution process.
Every breakdown is associated with one of the axes defined by the layout model. Several breakdowns may be projected onto a single axis in the layout table, as described in Section 6.3.2. Interactive tools MAY provide a mechanism to allow the user to pivot the table by moving breakdowns between axes and re-ordering breakdowns on the same axis.
A breakdown may consists of a fixed sequence of constraints, independent of the facts to be presented. Alternatively, the number, nature and ordering of the constraints may vary depending on the facts being presented.
A closed breakdown cannot directly depend on an instance. However, a closed breakdown may depend on parameters, which refer to the content of the instance document, but this dependency is indirect, and an application can provide values for variables.
An example of an open breakdown is one that breaks down facts by period. For presentation of existing data, this requires a row/column for each period against which a fact is reported. For data entry, it requires the ability to dynamically create and populate new rows/columns as the user enters data.
A tool that supports data entry into open tables SHOULD provide a method for the user to create new rows or columns in dynamic regions of the table and to specify the necessary aspect values.
A structural node is a node in a breakdown tree. Each node contributes zero or more constraints to the breakdown.
A structural node may contribute no constraints, in which case it exists solely to group together its children (possibly contributing a header to the table axes; see Section 22.214.171.124).
The cardinality of a structural node is defined as the total number of individual sets of constraints it and its children contribute to the breakdown. The cardinality of a branch node is equal to the sum of the cardinalities of its child nodes.
A closed structural node does not depend on the facts in the instance to determine its constraints.
A closed structural node has been fully expanded during resolution, and is not further expanded during layout.
A breakdown that consists only of closed structural nodes is, by definition, a closed breakdown.
An open structural node is a structural node that cannot be fully expanded in the structural model because it requires knowledge of the facts to be presented.
An open structural node has exactly one participating aspect.
An open structural node is expanded to a number of layout nodes during partitioning.
[Jon Siddle: The ordering of this expansion needs to be defined by this specification. We discussed (at the Oxford F2F) using a simple default sort order provided such an ordering was well-defined in existing specs (xsd, xpath2, xslt). It appears that no such ordering exists. This is still an open issue. We did agree that a tool can always provide alternative (and interactive) sorting (e.g. on locale-dependent labels), but must support the default sort. ]
An open structural node semantically represents a set of values for a given aspect. For example, an open structural node may represent "all periods used in the fact source". For data presentation, the contexts are required in order to enumerate the periods which will ultimately determine the number of slices (e.g. rows or columns). For data entry, the open node acts as a placeholder for the periods period entered into the application. The application MAY expand this placeholder according to the values already entered and / or MAY display a placeholder directly, possibly using it to accept new data.
A breakdown that contains at least one open structural node is, by definition, an open breakdown.
A roll-up node contributes no additional constraints to a breakdown. It is always the first or last child of its parent, but is not otherwise different from its non-roll-up equivalent.
A processor MAY choose to merge the header cell corresponding to a roll-up node with its parent when rendering the table.
A closed structural node may be associated with one or more labels, for the purpose of labelling the header cells it contributes to the layout table. Every header cell corresponding to a given structural node shares the same labels. Open structural nodes do not have labels. The labelling of header cells is described in Section 3.3.4.
For any node which has no labels, processors are free to choose a label corresponding to that node's constraints. For a node with a single concept or explicit dimensional member, processors SHOULD use one or more labels associated with the concept in the DTS.
Any labels which are not explicitly attached to a definition node, which are attached to a structural node by a processor MUST be indicated as coming from the processor. In the infoset syntax, the "processor" value for the @source attribute is used.
It is desirable to allow the application to use existing labels corresponding to the node's constraints where possible. Where an appropriate label already exists in the DTS, an explicit label is NOT RECOMMENDED.
The concept aspect MUST participate in the table.
The absence of any other aspect has no effect on the structural model. See also Section 6.3.1.
Figure 4 illustrates the definition model.
@parentChildOrdering attribute on a table declaration
may have one of two values:
children-first. It defines the default placement of
roll-up nodes contributed
by all closed definition
nodes in the table for which it is not overridden, as
described in Section 126.96.36.199.2.
@aspectModel attribute on a table declaration
contains an aspect model
identifier and specifies the aspect
model of the table. The aspect model determines which
aspects can participate in the table and its breakdowns.
A single table definition potentially defines multiple tables in the structural model. All tables in the structural model resulting from a single definition are grouped into a table set.
A table definition which references parameters resolves to a single table for each set of values for those parameters. A table definition with no parameter references resolves to a single table.
The context item for XPath expressions of table filters is each candidate fact being considered to meet the conditions that would make it an accepted member of the domain of the table.
A table-filter relationship is defined by an XLink arc which:
The arcrole value,
is declared in the normative schema supplied with this
@complement attribute on a table-filter relationship
indicates whether the filter's effect is inverted. A table-filter
@complement attribute has a value of
true uses the filter complement
rather than the filter itself.
The axes of a table are defined by breakdown definitions.
element is related to trees of definition nodes which define the
shape of the breakdown.
@parentChildOrdering attribute on a breakdown
defines the default placement of
roll-up nodes contributed by all closed definition nodes
in the breakdown (as described in Section 188.8.131.52.2) and overrides the value inherited
from the table.
The ordering of breakdowns
is the order of the table-breakdown relationships, as defined by
attributes. Where no order attribute is specified on a
relationship, or if two relationships have identical order
attributes, the relative ordering is implementation-defined.
However, it MUST be deterministic. Ordering of
breakdowns is only significant for relationships that have the
same value for their
A definition node is a definition of zero or more structural nodes in the structural model.
This section specifies syntax and semantics common to all types of definition node.
Definition nodes contribute nodes to the structural model through the resolution process (described in Section 6.2). The specific contribution to the structural model depends on the type of definition node, and is described in the corresponding section for a given type of definition node.
Definition nodes and the structural nodes they contribute are classified as either "closed" or "open".
Definition nodes MAY be extended using qualified attributes in other namespaces. Any such attributes MUST NOT affect the meaning of anything defined by this specification.
A closed definition node is a definition node which resolves to one or more closed structural nodes .
The figure below provides a model of the closed definition nodes.
There are two types of closed definition nodes defined by this specification:
Those which resolve to a single structural node, or
two structural nodes where one is a roll-up node and is a child of
the other. This type of definition node may have children. Given
such a definition node
D which resolves to
S is either
the single contributed node, or the parent node if two nodes are
contributed), any of the top-level structural nodes contributed by
D are children of
Those which resolve to a tree of structural nodes and may depend on the DTS. For example, a single closed definition node may resolve to a tree of structural nodes representing a concept tree. This type of definition node cannot have children.
<table:closedDefinitionNode>type at the starting resource of the arc
<table:closedDefinitionNode>type at the ending resource of the arc
The ordering of the children is the order of the definition-node-subtree relationships, as defined by their order attributes.
Wherever a definition node contributes a roll-up node, the position of
the roll-up node relative to its siblings is determined by the
effective value of the
@parentChildOrder attribute on
the contributing definition node, which can take either of two
parent-first: the roll-up node MUST be laid out as the first child of its parent node. This is the default value.
children-first: the roll-up node MUST be laid out as the last child of its parent node.
This attribute may be specified on the
<table:table> element, a table:breakdown element, or any
element in the
definition nodes that specify no value inherit a value
from their parent node or,
ultimately, from the parent breakdown definition
element if either specifies a value, otherwise the default value
parent-first is used.
An open definition node is a definition node which resolves to an open structural node.
A open definition node cannot have any children.
Aspect nodes are examples of open definition nodes.
A breakdown may be the source of more than one breakdown-tree relationship. The ordering of the individual breakdown trees is the order of the breakdown-tree relationships, as defined by their order attributes. Where no order attribute is specified on a relationship, or if two relationships have identical order attributes, the relative ordering is implementation-defined. However, it MUST be deterministic.
A number of concrete definition nodes are defined by this specification.
This section specifies semantics and syntax constraints for rule nodes.
The figure below provides a model of the rule node.
A rule node is a closed definition node that defines a structural node whose aspect constraints are defined by aspect rules. It may define an additional roll-up node which has no aspect constraints.
For example, a rule node may specify that a given slice (e.g. a row or column) should be constrained to facts reported against a certain period, or dimension member.
For example, a non-abstract rule node whose children constrain facts to different members of an explicit dimension will typically have as its own constraint the default member of that dimension. In this case, the constraints specified by the children take precedence over that of the parent. The roll-up node has no constraint, and so the constraint specified by the parent applies.
The constraints of a structural node resolved from a rule node are defined by the formula aspect rules in the corresponding definition node.
This specification reuses this construct, but alters its interpretation in the following ways:
@abstract attribute on a
element determines whether the node is abstract or not. This has
implications for how it
resolves (see Section 184.108.40.206.3). The default value is
An abstract rule node is a rule node that is
represented by a
<table:ruleNode> element with
element MAY contain one or more elements
<formula:aspectRule> substitution group. These
are used to specify aspects and aspect constraints for the node.
<formula:aspectRule> element specifies an aspect
and its value in a manner that is usable both to select input
fact(s) that match (for data presentation) and to specify output
aspects for new facts (for data entry).
<formula:aspectRule> features are NOT
@source (all rules) and
<table:ruleNode> MAY have
<formula:aspectRule> elements that have an
The context item when evaluating any XPath expression in
such an aspect rule is undefined. XPath expressions
MAY refer to variables as described in
Section 3.2.7. XPath
expressions SHOULD be evaluated when
constructing the table, but are not expected to be
re-evaluated as data is entered (if used for data entry).
[Herm Fischer: Should it be an error if a concept or dimension member qname is not recognized? We're already testing for bad dimension QName (xbrlfe:badUsageOfExplicitDimensionRule).][Roland Hommes: An XPath expression on an instance that does not exists will result in a high level XPath error message. ][Herm Fischer: No XPath-level error, the XPath expression only produces a QName, but the QName has no requirement in XPath to correspond to an existing schema element or anything else. If the rule were to specify a dimension member not existing, in financial filings with extensions, it would probably be necessary to not worry if the extension did not have some dimension that was QNamed.]
<table:ruleNode xlink:type="resource" xlink:label="parent" abstract="true"/>
<table:ruleNode xlink:type="resource" xlink:label="child1">
<table:ruleNode xlink:type="resource" xlink:label="child2">
<table:definitionNodeSubtreeArc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/PWD/2013-05-17/definition-node-subtree" xlink:from="parent" xlink:to="child1" order="1"/>
<table:definitionNodeSubtreeArc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/PWD/2013-05-17/definition-node-subtree" xlink:from="parent" xlink:to="child2" order="2"/>
Defines two columns of a table. The parent rule node
is abstract and thus contributes no columns itself.
The two child nodes each define a single columns and
constrain the value of the
<table:ruleNode xlink:type="resource" xlink:label="parent" parentChildOrder="children-first">
<table:ruleNode xlink:type="resource" xlink:label="child">
<table:definitionNodeSubtreeArc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/PWD/2013-05-17/definition-node-subtree" xlink:from="parent" xlink:to="child"/>
Defines two columns with identical constraints to the
previous example. The second column is a roll-up
contributed by the (non-abstract) parent rule node.
The parent node constrains the value of the
A rule node,
D, always contributes a single
S, as a child of the structural
node to which the parent of
All children of
D resolve to children of
Placement of the roll-up
node is determined by the effective value of the
@parentChildOrder attribute, as described in
Section 220.127.116.11.2: if
@parentChildOrder attribute has a value of
parent-first, the roll-up node is the first
child; if the
@parentChildOrder attribute has a value
children-first, the roll-up node is the last
child. Figure 8 shows the
The roll-up node contributes no constraints, so the constraints of its ancestors apply.
A rule node label associates a generic label or generic reference with a rule node.
During resolution, the labels associated with a rule node are associated with the sole resulting structural node (if there is only one) or the parent structural node (if there are two).
A processor MAY add labels to the structural nodes contributed during resolution as described in Section 18.104.22.168.
This section specifies the semantics and syntax for relationship nodes. Relationship nodes provide an implementation of closed definition nodes that expand into a tree of structural nodes, defined by networks of concepts or explicit dimension members in a DTS.
Figure 9 below provides a model of relationship nodes.
A relationship node defines a tree walk of part of a concept or dimensional network.
A relationship node resolves to an ordered tree of
structural nodes representing its tree walk. Each node
constrains the relevant aspect (the concept aspect in the
case of a concept-relationship node or an explicit dimension
aspect in the case of a dimension-relationship node) to a
single value. The order of sibling nodes is given by the
the relationships by which the concepts or
dimension members associated with the nodes were discovered.
The ordering between a parent node and its children is
defined by the relationship node itself. It can be specified
@parentChildOrder attribute on the
element. There are two valid values of this attribute:
parent-first, specifying that the parent node's
slice (e.g. a row or column)
should appear before its children, and
children-first, which specifies that it should appear
after. If no value is specified, one is inherited from the
@parentChildOrder on the
<table:table> element (which defaults to
parent-first if unspecified).
A relationship node can use XPath expressions to identify its tree walk. These expressions may depend on parameter variables. A dependency on a parameter variable which evaluates to a sequence will produce a table in the table set for each value in the sequence, as described in Section 22.214.171.124. [Victor Morilla: This paragraph should be replaced by a reference to section 3.2.7]
The evaluation context of these XPath expressions includes all parameter variables defined in the linkbase, but do not include any variables defined by other definition nodes. This allows the structure of a breakdown to be determined independently of other breakdowns.
Relationship nodes do not have any labels. A processor SHOULD add labels to the structural nodes contributed during resolution as described in Section 126.96.36.199.
If a relationship node has a
@name attribute, then the
named XPath variable binding is to the xfi:relationship.type
[XPATH AND XQUERY FUNCTIONS] object which can be referenced in
XPath expressions to access values of relationship attributes
definition nodes that include the
<formulaAxis> element[Jon Siddle: I think
"in the value of the axis element" would be clearer],
@name attribute is not bound to an object when
evaluating the initiating end of the relationship (e.g., a
parent for descendants), so that XPath code
MAY use the
empty function to
determine that the evaluation is for such a situation. In this
case, only the
@conceptqname variable, if provided,
has a non-empty binding.
A relationship node MAY specify a
relationship source concept (by
<formulaAxisExpression> specifies whether the source
concept is included in the rendered concepts, by the
-or-self suffix on the
<formulaAxisExpression> result. If the
-or-self is not present, the top level
rendered concepts are the children of the source concept.
The behaviour of relationship nodes with each combination
of source concept and
described in Table 2 below.
when the suffix
||The root relationships are equivalent to a virtual root source concept that has the root concepts of the network as children.|
The top level rendered relationship is a virtual
relationship that has as its child the named
relationship source. If the current binding is to a
source object, any
when the suffix
||The root relationships are the relationships whose source is a root concept of the network, causing the children of these root concepts to be the top level of rendered concepts.|
|present||The top level rendered relationships are the relationships that have as their parents the named relationship source, causing the children of the relationship source to be the top level of rendered relationships.|
If the relationship source is specified and is neither a concept QName in the DTS of the instance being rendered, nor a source of a relationship, no relationships are found but an error is not raised (this is necessary to deal with financial report filing extension taxonomies that may or not have certain relationships or concepts),
If a relationship node has a
then the named XPath variable binding is to the QName of the
concept which is the relationship source (if
-or-self is specified and the current binding is to
the source), or the relationship target (if the current binding
is to a target of a relationship). The conceptname variable is
a QName value which can be referenced in XPath expressions to
access xfi functions for which concept QName is an argument
(such as to retrieve a label).
A relationship node is represented by a
rule for XBRL 2.1 base set (concept to concept) relationship nodes, and by a
rule for dimensional relationship nodes.
Both of these relationship node elements have:
<table:relationshipSourceExpression>elements, which if present, are respectively QNames or QName expressions identifying source concept(s) (origins) for "tree walking". The
<table:relationshipSource>MAY be omitted, in which case the special QName xfi:root is assumed. QNames that aren't source concepts for relationship elements in the indicated network are ineffective but not an error.
-or-self, to indicate that the source element (such as root elements of a financial statement, or the source element of a tree walk, is to be included in the rendered table (otherwise just the to concept (descendants) or from concept (ancestors) is rendered. When
-or-selfis specified, this causes an artificial relationship to appear above the root element, which is a xfi:relationship.type object, established for each such source element, having no arc or link attributes or names. Valid values for the
<formulaAxis>element are specific to each type of relationship node and are described in the relevant sections below.
<table:generationsExpression>expression, which is the same as for
xfi:concept-relationships(and optional in the same manner). Generations must be ignored or 1 for a parent, child, or sibling definition node.
<table:linkroleExpression>element which is respectively a non-empty URI or an expression (
xl:nonEmptyURI?). If none is specified, or the expression produces an empty sequence, all link roles are considered.
[Roland Hommes: What does it mean when table:generations is both optional and must be ignored?][Herm Fischer: It means if you ask for 2 generations of child, parent, or sibling you still only get 1 generation, corresponds to the xfi:concept-relationships. Maybe less convoluted to say generations is optional and only processed for descendant and ancestor axes, otherwise ignored?][Jon Siddle: I think it should be an error if generation is present and not 1 for these axes]
The relationship node MAY have elements that
have an XPath expression.
The context item for each XPath expression is the standard input
<xbrli:xbrl> element. XPath expressions
MAY refer to parameters and XPath variables
that MAY be assigned by other nodes, such as
other relationship nodes
@conceptname, when in effect. XPath expressions that
refer to a context item or
<xbrli:xbrl> element, and to
xfi functions such as
xfi:facts-in-instance, will be processed when the
table is constructed and are not expected to be dynamically
updated if users enter data to cells of the table.
The XPath expressions of a table rendered with no input instance
shall nonetheless appear to have a context item and childless
<xbrli:xbrl> element, and corresponding xfi function
behavior, such as an empty sequence result from
A concept relationship node is a relationship node which defines a tree walk of a concept network.
<formulaAxis> element, valid values correspond
to those for
[CONCEPT RELATION FILTERS]. The token suffix
-or-selfMAY be specified as
noted above to request including the relationship source.
In addition to the general properties of relationship nodes, a concept relationship node can specify:
<table:arcroleExpression>element, which is respectively a non-empty URI or an expression (
<table:linknameExpression>element, which is respectively QNames or QName expressions (
<table:arcnameExpression>element, which is respectively QNames or QName expressions (
As described in Section 188.8.131.52, a relationship node must unambiguously identify the tree walk. Since concept relationship networks are defined by XBRL 2.1 Base Sets (which are identified by arc role, link role, arc element and link element), this imposes the following requirements for concept relationship nodes:
A dimension relationship node is a relationship node which defines a tree walk of a dimensional network.
<formulaAxis> element, valid values correspond to
[DIMENSION FILTERS]. The token suffix
-or-selfMAY be specified as
noted above to request including the relationship source.
In addition to the general properties of relationship nodes, a dimension relationship node has additional properties:
<table:dimensionExpression>element which is respectively a QName or a QName expression (
xs:QName?). The expression may produce an empty sequence to indicate that it is not constraining the dimension relationship node.
@targetRoleand consecutive arc roles as defined for dimensions [DIMENSIONS].
[Roland Hommes: Errorcode if table:dimension refers to a QName that is not a dimension concept?][Herm Fischer: Error could correspond to xfie:invalidDimensionQName in formula functions, but this may be restrictive on financial reporting with extensions, where the dimensions and even their names may be unknown to the table linkbase author.]
As described in Section 184.108.40.206, a relationship node must unambiguously identify the tree walk. Since dimensional networks are defined by Dimensional Relationship Sets, this imposes the following requirements for dimension relationship nodes:
If any relationshipSource is specified, it is the QName of the dimension member that the selection criteria specified by the definition node parameter are going to be applied relative to.
If a linkrole is provided, then it specifies the base set in which the primary items are associated to the combination of hypercubes that is the 'head' of the DRS, e.g., the relationship source primary item concept is the DRS head primary item or inherits hypercubes from it, and the effective domain is consecutively related to that base set's hypercubes. If a linkrole is omitted (or its expression yields an empty sequence) then all DRS members of the specified definition node are provided, for all base sets in which the relationshipSource and dimension (if provided) are related to hypercubes.
An aspect node is an open definition node which directly specifies a single participating aspect, and optionally a restriction on the facts used during partitioning to determine the included values for that aspect.
The figure below provides a model of the aspect node.
An aspect node has exactly one participating aspect, which is specified directly.
Dimensional aspect specifications have an optional
@includeUnreportedValue property (which defaults to
false) which specifies whether the expansion should include a
"no value" placeholder when facts exist which have no value for
During the partitioning phase of the
layout process, an aspect node expands to one layout node for
each distinct value of its participating aspect present in its
set of contributing
facts, plus a single layout node representing the
absence of a reported value for the participating aspect if
true and the
facts include at least one fact where no value is
reported for the participating aspect.
An aspect node can be associated with Formula filters to constrain the contributing facts used for this expansion.
Note that the filters constrain the facts used to determine the aspect values which should be included during partitioning, but they do not contribute any constraints to the table.
If the facts present in the fact source as as follows:
|Concept Aspect||Period Aspect||Fact Value|
Given the following definition of aspect node and associated filter:
The resulting table would look like this (assuming a suitable definition of the y-axis with concept as a participating aspect):
The filter restricts the contributing facts to those with "profit" as the value for the concept aspect. The period aspect node then expands to a node for each value of the period aspect. There is no fact reported against the "profit" concept for the "2012" period, so only 2011 and 2013 are included. The constraints on the nodes on the x-axis only constrain the period aspect, so the values for the "assets" concept still appear in the final table.
This allows the y-axis provides constraints for the concept aspect without causing an xbrlte:aspectClash.
Aspect nodes do not have any labels. During partitioning, a processor SHOULD add labels to the layout nodes as described in Section 3.3.4.
An aspect node is represented by a
element with exactly one child element in the
<table:aspectSpec> substitution group and optionally
one or more
<variable:filter> resources related by
axis filter arc relationships.
The child element in the
substitution group specifies the participating aspect of the
<table:unitAspect> elements specify the concept,
entityIdentifier, period and unit aspects respectively.
<table:dimensionAspect> specifies a dimensional
aspect by the dimension's QName. It has an optional
@includeUnreportedValue attribute (which defaults to
false) which specifies the includeUnreportedValue property of
the aspect node.
The context item for any XPath expression associated with an aspect node filter is the fact from the fact source being considered for inclusion as a contributing fact for the aspect node.
Filters MUST be evaluated when rendering an existing instance. An application supporting data entry MUST ensure that the facts entered into cells satisfy the associated filters but MAY defer this check until the instance is serialised.
To declare a aspect-node-filter relationship an XLink arc MUST:
<table:aspectNode>element at the starting resource of the arc
The arcrole value,
http://xbrl.org/arcrole/PWD/2013-05-17/axis/aspect-node-filter, is declared in the normative schema supplied with
An aspectNode with a complemented aspect-node-filter relationship to a filter uses the filter complement in its implied XPath expression.
XPath expressions in definition nodes may refer to global parameter variables or variables defined by ancestor nodes in the same breakdown or nodes in any preceding breakdown projected onto the same axis.
For example, a definition node for breakdown by presentation linkbase concept, which is further broken down by a definition linkbase filter, referring to typed dimensions present for the concept of this breakdown, may refer to the presentation linkbase concept above the typed dimension filtering breakdown (both explicitly in an expression, and implicitly by the fact set it processes to determine the structure).
XPath expressions may contain variable references to variables defined by other XPath expressions which need to be evaluated first. This creates a chain of evaluation dependencies which must be evaluated in a certain order.
Processors MUST raise an error if variable references form cyclic dependencies.
Processors MUST be able to resolve a valid chain of variable references.
The layout model directly represents the layout and content of each table in a layout, where the content of a table includes both data, derived from XBRL facts, and header information documenting the meaning of that data.
A layout table represents an arrangement of selected XBRL facts following a matrix layout in a Cartesian space with x, y and z axes.
This specification describes three axes: x, y, and z. The following conventions for interpreting the different axes SHOULD be followed by rendering software where the output format allows it.
Each position along an axis, corresponding to a slice (e.g. a row or column) in the table, is associated with a set of constraints on the fact space. An axis may be composed of multiple independent breakdowns of the fact space. These are combined by projecting them onto the axis, as described in Section 6.3.2.
Each one of the possible combinations of constraints along a table's axes, corresponding to a single cell in a table, is referred to as a coordinate.
An axis may be associated with several rows (or columns) of headers, indicating multiple sets of nested constraints on the values displayed in the columns (or rows) of the table. Column (or row) spanning of individual cells SHOULD be used to indicate nesting of constraints, where the output format allows it. Axis headers MAY be simplified when tables are rendered on media not meant primarily for human readability (such as CSV files, which lack a way to span or merge headers).
For a header cell which has one or more labels associated with it (during resolution from the structural model), the processor MUST select one or more of these labels for rendering the header cell.
For a header cell which has no labels:
The number of labels associated with a header cell has no impact on the logical structure of the layout model. A processor MAY render multiple labels for the same header cell as if they were distinct cells.
Header cells which are at the same logical level SHOULD be aligned when rendering.
If multiple labels for the same header cell are rendered, the @order attribute MUST be honoured.
Each cell contains the facts (if any) that match the constraints associated with the particular row and column at whose intersection they are located, as well as any global constraints associated with the table.
A fact matches a set of aspect constraints if, for every participating aspect, each aspect value of the fact corresponds to the aspect specified by the constraints.
A cell may contain zero or more facts. If more than one fact is associated with a cell then the behaviour is implementation-defined. A tool MAY choose to display all or a subset of the values. Alternatively, a tool MAY display a visual indication that the cell contains multiple values.
In tools that support data entry, a cell may be editable, to allow a user to enter new facts or to edit existing facts. This specification places no restrictions on how tools present this editing functionality to users.
The source for a table used for data presentation is the collection of domain objects considered for table filter matching, axes coordinate matching, and presentation as a cell value.
The source for a table used for data entry is an instance that does not have the facts to be entered (or may have facts with earlier values, to be edited).
This specification defines two "infosets", which are serialisations of two of the three models.
The layout infoset is an XML serialisation of the layout model. The syntax is defined by the normative schema supplied with this specification (see A.2).
For most of the XML elements in the infoset, ordering is significant and corresponds to the order in which the corresponding cells in the table are laid out, as outlined below.
The layout infoset is used by the conformance suite to compare layouts produced by tools implementing this specification to those expected from a conformant processor.
A table set may be
optionally associated with a set of headers, which apply to the
individual tables in the set. These are grouped together under a
<tablemodel:headers> element. The content of the
<tablemodel:headers> element is identical to that
of the axis headers described in Section 5.2.3, but there is no attribute to
associate them with a table axis. As the table set headers are
associated with tables, the total number of spanned header 'columns'
should be equal to the number of tables in the table set and the
order in which they are specified should be the same as the order of
tables in the infoset document.
Each table set must have at least one child
<tablemodel:table> element must have as its children:
<tablemodel:cells>element describing the contents of the table cells
<tablemodel:headers>elements describing the headers for each axis of the table.
@label attribute on the
<tablemodel:table> element is used to label each table.
The headers for an axis are declared by a
<tablemodel:headers> element groups together a sequence of zero or more
<tablemodel:header> elements, one for each row (or column) of header cells.
These are ordered starting from the outside of the table (i.e.
farthest from the data cells) and working inwards.
The required attribute
@axis indicates which of the
three defined axes a
<tablemodel:headers> element is associated with.
Valid values of this attribute are
z. Only one
<tablemodel:headers> element may be associated
with each axis for a given table.
<tablemodel:header> element contains a sequence
<tablemodel:label> elements. Each
element describes the label associated with a single header cell.
These are ordered according to the natural direction of ordering in
the rendered table.
@source attribute on the label element indicates
where the label originated. If the label was not associated
explicitly with a definition node, this attribute
MUST be provided with a value other than
Spanning of multiple rows or columns in the table is indicated in
the infoset by an optional
@span attribute on the
<tablemodel:label> element. The value of this attribute is a positive integer
giving the number of table columns spanned by the header cell. If
the attribute is not specified then a span of 1 is assumed. The
total number of columns spanned by all the labels on each header row
for a given axis should be the same.
Roll-up nodes are indicated by an optional
attribute with a value of
Each cell is represented by a single
<tablemodel:cells> represents a dimensional slice
of the data. The number of dimensions involved in the slice depends
on the level of nesting.
A series of
elements is contained in a
element, which represents a one dimensional sequence of cells along
a single axis, indicated by the
@axis attribute on the
element. The position of each cell along the indicated axis is
determined by its position within the containing
The most nested
elements may each be contained in another
element, which represents a two dimensional slice of cells along
another axis. These in turn may be nested inside a single
element, representing a three dimensional slice (of which there is
In this way, each level of nesting addresses a more specific part
of the data. The position of a child element
P with an
A determines the position along axis
A of all cells which are descendants of
<tablemodel:cells> element contains either a
<tablemodel:cell> elements, or a sequence of
<tablemodel:cells> elements. Each
element must specify (using the required
attribute) the axis along which its contained slices or cells are
The value of the
@axis attribute on a
element must be one of the three axes defined by this
sibling elements must have the same value for the
@axis attribute. Elements must never have the same
value of the
@axis attribute as one of their
The text content of a
element describes the content of a single data cell.
[Jon Siddle: I believe this section is correct and reasonably precise. The complexity of the description far outweighs the complexity of what it is describing (they're just nested arrays). It needs some diagrams to make this simpler to understand. I'd also like to avoid using the term "dimension" here, but that's probably unavoidable.]
Compilation is the process of parsing the table linkbase and producing a definition model.
During compilation, XPath expressions MAY be compiled and variable references validated against the restrictions described in Section 3.2.7.
The resolution process has the DTS available, but not a fact source (for example, an instance), so that it produces a structural model that is useful both for data entry and data presentation.
A single table definition can define multiple tables in a table set in the structural model, according to the values its parameters can take, as described in Section 220.127.116.11.
Implementations MAY provide a series of values for each parameter to produce multiple tables (the table set), or they MAY provide a single value for each parameter to produce a single table (this may be seen as "selecting" a table from the table set).
Given a single value for each parameter, a single table in the structural model is produced by resolving the table definition. Resolution of a table definition to a table set for a series of values for its parameters is equivalent to sequentially resolving against a single set of parameter values, for each set of parameter values in the series.
The general process of resolving a table definition to a table structure is described here. The individual descriptions of definition node types describe how they contribute to the structural model.
Each breakdown in the definition model is resolved to a breakdown in the structural model by following the resolution rules for each node in the breakdown definition.
The resulting tree of structural nodes is based on the tree of definition nodes. Each node in the definition model resolves to one structural node, a tree of structural nodes or a list of structural nodes.
Dexpands to a single structural node
S, the parent of
Sis the structural node to which the parent of
Dhas no parent,
Shas no parent. Note that the parent of
Dcannot resolve to more than one structural node, since only a closed definition node which expands to exactly one structural node can have children (as described in Section 18.104.22.168).
Dexpands to a tree of structural nodes, with structural node
Sbeing the root of this tree, the parent of
Sis the structural node to which the parent of
Dhas no parent,
Shas no parent. The non-root structural nodes in the expansion are arranged as described in the specification of the definition node.
Dexpands to a list of structural nodes
S1..Sn, the parent of every structural node
S1..Snis the structural node to which the parent of
Dhas no parent,
S1..Snhave no parent.
Despite representing a number of aspect values, and ultimately a number of columns or rows in the rendered output, open definition nodes expand to one open structural node since they depend on a fact source (typically an instance). The resulting open structural node represents a part of the table which is dynamic.
Height-balancing is performed so that there is an unambiguous correspondence between nodes on the same level of the breakdown (and an unambiguous alignment of header cells in the final rendering).
This is particularly important when projecting multiple breakdowns onto an axis.
Height-balancing adds a single roll-up node at each level under any leaf nodes up to the required depth.
The facts of a table may exist in an XBRL instance (data presentation), or they may be new facts created from information entered into a tool by a user to produce a new or edited output XBRL instance (data entry). In the latter case, the table provides a description of the facts that may be entered.
A fact is said to belong to a table if its aspect values place it in the domain of the table.
[Herm Fischer: I think this is the wrong term and should be replaced with the notion of binding (as in formula variables), for next edit pass. Then there is a lot under processing that will use this term (as with formula binding and processing).]
The layout process may be interactive. Examples of interactive layout include allowing the user of a tool to move breakdowns between axes or select the language in which axis headers and text-valued facts are displayed.
A layout is a result of the layout process.
The non-participation of a dimensional aspect in the table implies the absence of a corresponding aspect value for the facts in that table. Facts which have a non-default aspect value for any dimensional aspect not participating in the table MUST be excluded.
For explicit dimensions with a default, this will have the effect of only including facts for the default member.
For explicit dimensions without a default, and for typed dimensions, this will have the effect of only including facts not reported against that dimension.
The non-participation of non-dimensional aspects causes the cells in the table to be unconstrained with respect to those aspects.
The handling of this case is application defined, and is described in Section 22.214.171.124
Multiple facts may match the constraints for a single cell. In this case, the behaviour is application dependent. Applications MAY choose to handle this in one of the following ways:
Multiple breakdowns may be associated with a single table axis. Breakdowns on an axis are according to the
attributes of the
table-breakdown relationships linking their definitions
to that of the table.
Two breakdowns associated with the same axis are combined to form a new effective breakdown by attaching an identical copy of the second breakdown to each leaf of the first breakdown, such that the root nodes of the second breakdown become the children of the leaves of the first breakdown, as illustrated in Figure 11. This process is repeated for further breakdowns by combining each additional breakdown with the current effective breakdown in the same way.
The resulting sequence of constraints is the Cartesian product of the sequences of constraints defined by each individual breakdown, ordered lexicographically (such that each constraint from the first breakdown is taken, in order, in combination with each constraint from the second breakdown, also in order, and so on).
The projection in
Figure 12 involves a more
complex breakdown, that includes two roll-ups (
requires padding with an additional roll-up node to bring the first
breakdown tree to a uniform
depth (see Section 3.1.4), thus ensuring that the
individual breakdowns line up correctly in the effective breakdown.
As part of the layout process, headers are constructed for each axis of the table. Axis headers are produced after projecting the breakdowns in the structural model onto axes, as described in Section 6.3.2.
Axis headers are
constructed from nodes in the structural model. Each
breakdown contributes a
number of rows/columns of header cells to the header for the axis with which it is associated. Each
level of a breakdown tree
contributes a single row/column of header cells to the header, with each structural node contributing
zero or more header cells. Header rows are ordered first by the defined
order of the breakdowns
(initially given by the
@order attribute of the table-breakdown
relationships) and then by depth within each breakdown tree.
Elimination is the process of eliminating unpopulated rows and columns to produce a more compact table.
An unpopulated slice (e.g. a row or column) of a table is one whose constraints match no facts when populating the table.
[Jon Siddle: I'm not happy with this word, but "expansion" is already taken. On the plus side, partitioning implies you're splitting something that exists (which is accurate since we're operating on facts at this point).]
This partitioning depends on the fact source (possibly a dynamic fact source used for data entry), but is otherwise similar to expansion
An open structural node contributes one layout node for each value of each partitioning aspect it defines. Every open definition node must define the partitioning aspects of its corresponding structural node.
Given a set of facts from the fact source, the layout process MUST constrain these facts to those which satisfy all table filters (if any) associated with the table.
These facts are MUST be arranged in the table according to the constraints associated with its slices (e.g. the columns, rows and positions along the z-axis).
Tables using only closed structural nodes have a fixed structure in that they don't depend on facts in a fact source, so the same process can be used to construct tables for data entry as for data presentation ( Section 6.3.6).
Open definition nodes define a part of the layout model which depends on the facts in a fact source. For data entry, these facts can change (and the fact source will often be empty to begin with).
Processing software which supports data entry MUST use the partitioning aspects of the open definition nodes to allow the user to dynamically add aspect values for these partitioning aspects. These aspect values MUST be validated against the constraints defined by the open definition nodes.
For example, if an open definition node defines period as a partitioning aspect, but defines no constraint, the user should be able to create new columns for any period. If an open definition node defines a typed dimension as a partitioning aspect, constraining values to a be numeric, the user should be able to create new columns for that dimension and the user should either be prevented from entering non-numeric values or any non-numeric value entered should cause a validation error after entry.
The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.
NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:
http://www.xbrl.org/PWD/2013-05-17/- during the drafting process for this specification this directory should contain a copy of the most recent published version of the schema at http://www.xbrl.org/PWD/2013-05-17/table.xsd.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).
This document could not have been written without the contributions of many people.
|01 October 2011||Herm Fischer||
|09 October 2011||Victor Morilla||
Added comments on issues that require further disucssion
|11 October 2011||Hugh Wallis||
Identified unresolved issues and commented them for publication and feedback solicitation
|28 October 2011||Herm Fischer||
Working group updates: position of coordinate in axes
|03 November 2011||Herm Fischer||
Working group updates: replace predefinedAxis model with subtrees of ruleAxes and compositions of ruleAxes with relationshipAxes. Replace axis-member notion with that of axis subtree composition.
|05 December 2011||Herm Fischer||
Update class diagram, provide schema definitions.
|19 December 2011||Herm Fischer||
Editorial updates suggested by Roland Hommes in WG e-mail of 2011-12-08.
|23 April 2012||Herm Fischer||
Editorial updates suggested by Takahide Muramoto in WG e-mail of 2012-04-11. Includes new error code axisValueClash, clarification to syntax. parentChildOrder has an example where the parents are first at an outer level of nesting and children are first in more detail breakdowns nested within.
|08 May 2012||Herm Fischer||
Clarified use of coordinate (orders among axes dispositions taken together) and ordinate (ordering along a single axis disposition).
Added Message can be used to label headers in table
|28 May 2012||Herm Fischer||
Added parentChildOrder attribute to table, made attribute optional in schema, added that it is inheritable, and added an error code of there is no value specified or inheritable on a predefinedAxis element.
|30 May 2012||Herm Fischer||
Added parentChildOrder table default parent-first, per F2F WG agreement.
Added explanation of axis headers, per F2F WG agreement.
Moved rendering attributes to CSS specification, per F2F WG agreement, added class attributes to relationships.
|10 July 2012||Herm Fischer||
Added axis-selection-message arcrole arelationship.
|11 July 2012||Herm Fischer||
Per WG decision 2012-07-04, merged separate specs into this spec: rule axis, composition axis, relationship axis, tuple axis, selection axis, and filter axis.
|21 July 2012||Herm Fischer||
Editorial updates suggested by Roland Hommes :
(a) removed error code error-missing-parent-child-order-attribute as
WG agreed to a parentChildOrder inherited from of table element
which has a default;
(b) removed references to standard labels, as they can only apply in
message constructs (due to need to handle role selection when
appropriate to relationship axes);
(c) clarified that language selection for axis headers applies to
label and messages;
(d) clarified ordering of a single ordinate's multiple axis headers
|01 August 2012||Herm Fischer||
Editorial updates suggested by WG e-mails from Shogo Ohyama : (a) Filter axes wording in paragraph 1 of Section 126.96.36.199.1. (b) Filter axes with XPath expressions dependent on other ordinate values by variable names, in Section 188.8.131.52.4.
|26 October 2012||Jon Siddle||
Re-organise content to fit the new three-model approach.
|08 November 2012||Jon Siddle||
Rename (eg axis -> breakdown) according to WG discussion and editorial changes.
|09 November 2012||Jon Siddle||
Add more details on the structural model.
|12 November 2012||Jon Siddle||
Improvements to wording and formatting. Clarify some definitions.
|13 November 2012||Jon Siddle||
Define top level use cases, reorder model descriptions and fix schema validation issues.
|19 November 2012||Jon Siddle||
Clarify various descriptions (particularly in relation to open and closed tables and ordering). Updated figures. Some rewording and formatting improvements.
|21 November 2012||Jon Siddle||
Clarify restrictions on defined axes and tables in a table linkbase. Use new terms more consistently. Update naming for consistency.
|26 November 2012||Jon Siddle||
Shuffling of content and rewording, especially in the definition model section.
Remove remaining uses of "ordinate".
Added missing description. Some formatting improvements.
|28 November 2012||Jon Siddle||
Expand and clarify a number of descriptions. Some grammar, broken reference and schema validity fixes.
Define missing terms. Describe participating aspects and change uses of "covering" to "participating" where appropriate.
|29 November 2012||Jon Siddle||
Improve subsection headings.
Clarify and expand on descriptions for shape of the table, table cells, coveredAspect, etc.
|06 December 2012||Jon Siddle||
Further wording and formatting improvements.
Update rendering model, incorporating some of the suggestions made in the comments. Add a preliminary definition for cells.
|11 December 2012||Jon Siddle||
Move definitions of models. Other minor changes to clarify terminology. Reorganise and expand rendering sections.
|17 December 2012||Jon Siddle||
Clarification of xfi function usage. Move sections to be consistent with similar specifications, make example non-normative.
|20 December 2012||Jon Siddle||
Define abstract / non-abstract nodes and remove explicit roll-up nodes in the definition model, in accordance with WG resolution. Rewrite closed definition node description since previous assertions no longer hold.
Describe elimination, and tidy up some no longer relevant descriptions and an error code.
Improvements to abstract / non-abstract description.
Minor fixes (prefixes, example name, broken reference).
|21 December 2012||Jon Siddle||
Rendering model and rendering process updates.
Improve description of ordering and Cartesian product of breakdown constraint sets.
|07 January 2013||Jon Siddle||
Minor fixes (missing ID, orphaned comment, etc.).
|08 January 2013||Jon Siddle||
Rename @disposition to @axis in the infoset schema for consistency with the table linkbase schema.
|08 February 2013||Joshua Roache||
Change valid values for dimension relationship node formula axis elements to reflect those accepted by formula for dimension filters.
|19 February 2013||Jon Siddle||
Remove composition node (redundant), selection node (no use-cases for v1.0) and tuple nodes (agreed that v1.0 doesn't need special treatment of tuples).
|20 March 2013||Victor Morilla||
Removed some comments about issues already addressed in the spec. Added some additional comments
|20 March 2013||Jon Siddle||
Add a definition of effective constraints (specified or inherited) on a node, and define behaviour for leaf nodes not specifying all participating aspects, as agreed at the Oxford F2F
|26 March 2013||Jon Siddle||
Add a description of behaviour for unspecified aspects for a table, as agreed at the Oxford F2F.
Add a description of height-balancing for structural breakdowns to ensure they "line up" correctly (and unambiguously) when projected onto an axis.
|27 March 2013||Jon Siddle||
Clarify that only one breakdown per table is necessary.
|28 March 2013||Jon Siddle||
Some fixes and improvements around issues identified by Victor's recent comments.
Removed some stale comments which no longer apply.
Incorporated some of Roland's feedback.
Updated / added comments according to agreements from Oxford F2F.
|10 March 2013||Jon Siddle||
Redrafting of sections relating to labels and header cells, as agreed at the Oxford F2F.
|14 March 2013||Jon Siddle||
Redrafting around Dublin F2F discussions.
|25 April 2013||Jon Siddle||
Drafting aspectNode replacement for filterNode as per Dublin discussion.
|29 April 2013||Jon Siddle||
Added example of filter behaviour for non-participating aspects (in relation to aspectNodes).
|07 May 2013||Jon Siddle||
Fix a couple of errors noted in feedback to the group.
This appendix contains a list of the errata corrections that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Rendering Working Group up to and including 17 May 2013.
No errata have been incorporated into this document.