1 Introduction

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.

1.1 Relationship to other work

This specification depends upon the XBRL Specification [XBRL 2.1], the XBRL Dimensions Specification [DIMENSIONS] and the XBRL Formula Specification [FORMULA].

1.2 Namespaces and namespace prefixes

Namespace prefixes [XML NAMES] will be used for elements and attributes in the form ns:name where 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.

Table 1: Namespaces and namespace prefixes

Prefix	Namespace URI
`table`	`http://xbrl.org/PWD/2013-05-17/table`
`xbrlte`	`http://xbrl.org/PWD/2013-05-17/table/error`
`tablemodel`	`http://xbrl.org/PWD/2013-05-17/table/model`
`eg`	`http://example.com/`
`link`	`http://www.xbrl.org/2003/linkbase`
`xbrli`	`http://www.xbrl.org/2003/instance`
`xfi`	`http://www.xbrl.org/2005/function/instance`
`xbrldi`	`http://xbrl.org/2006/xbrldi`
`xbrldt`	`http://xbrl.org/2005/xbrldt`
`xl`	`http://www.xbrl.org/2003/XLink`
`xlink`	`http://www.w3.org/1999/xlink`
`xs`	`http://www.w3.org/2001/XMLSchema`
`xsi`	`http://www.w3.org/2001/XMLSchema-instance`
`gen`	`http://xbrl.org/2008/generic`
`variable`	`http://xbrl.org/2008/variable`
`formula`	`http://xbrl.org/2008/formula`
`tuple`	`http://xbrl.org/2010/formula/tuple`
`df`	`http://xbrl.org/2008/filter/dimension`

1.3 Document conventions (non-normative)

Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].

1.4 XPath usage

XPath usage is identical to that in the XBRL Variables Specification [VARIABLES], except that the context item is undefined unless otherwise stated.

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.

2 Uses

While this specification does not dictate how it may be used, it does define two main types of use:

Data entry is the use of this specification for the purpose of entering new facts or editing existing facts in an (possibly new) instance document.

Data presentation is the use this specification for the purpose of rendering instance data.

3 Models

Three models are defined by this specification:

The structural model represents the structure of each table, independent of the way it was defined and any details pertaining only to the way it will be rendered; it captures the meaning of the reporting tables.
The definition model defines the structural model using resources and relationships in the DTS. It is transformed into the structural model through the process of resolution.
The layout model describes how the tables should be laid out.

3.1 Structural model

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.

Related tables are grouped into table sets: sets of tables that share a common definition. The shape of each table is described in terms of hierarchical breakdowns of fact space.

Figure 1 shows the classes that participate in the structural model.

Figure 1: Structural model

3.1.1 Tables

A table represents a breakdown of XBRL fact space for the purpose of defining a reference view of XBRL data.

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.

Error code xbrlte:tableMissingConceptAspect MUST be thrown if the processing software encounters a table that does not include the concept aspect as one of its participating aspects.

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.

The arrangements of constraints in each of the breakdown trees that make up a table, taken together, define the shape of the table.

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.

Each axis consists of a sequence of slices, where a single slice represents a position along that axis. A slice along the x-axis is a column. A slice along the y-axis is a row.

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.

3.1.2 Table sets

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.

3.1.3 Constraints

A constraint is a restriction on the facts eligible to be presented or entered in a table cell, in terms of its aspect values.

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.

3.1.4 Breakdowns

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: Product and Geography (x-axis). Figure 3 shows (part of) the corresponding structural model (the constraints associated with each node are not shown).

Figure 2: Structural model example table

Figure 3: Structural model example

3.1.4.1 Breakdown labels

A breakdown may have associated labels. Each of these labels applies to the breakdown as a whole.

3.1.4.2 Uniform depth

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.

3.1.4.3 Aspect Constraints

The effective constraints of a node are those either specified by the node itself or inherited from its ancestors.

Where different aspect values for the same aspect are present in this path, the aspect value closest to the leaf is used.

An aspect which is identified by a structural node is a participating aspect.

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 3.2.1.1).

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 explicit and typed dimensional aspects, the absence of a reported value for that dimension is inferred. For explicit dimensions with a default, this is equivalent to constraining to that default.
For non-dimensional aspects, the absence of such a constraint is an error.

For example, the two nodes in Figure 3 with rollUp=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).

Error code xbrlte:aspectClash MUST be thrown if the processing software encounters two or more breakdowns in a table that address the same aspect.

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.

The aspect values associated with closed definition nodes can also be determined during the resolution process.

The aspect values associated with open definition nodes, cannot be determined until expansion occurs as part of the layout 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.

3.1.4.4 Closed breakdowns

A closed breakdown is defined as a breakdown whose sequence of constraints can be determined independently of the facts to be 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.

3.1.4.5 Open breakdowns

An open breakdown is defined as a breakdown whose sequence of constraints changes dynamically with the facts presented and thus cannot be completely determined without knowledge of those facts.

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.

3.1.5 Structural nodes

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 3.1.5.4).

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.

Structural nodes can be classified into two groups: open structural nodes and closed structural nodes.

3.1.5.1 Closed structural nodes

A closed structural node is a structural node with constraints fully determined by its definition and the DTS.

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.

Closed structural nodes can be roll-up nodes.

3.1.5.2 Open structural nodes

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.

3.1.5.3 Roll-up nodes

A roll-up node is a closed structural node which represents an aggregation of its siblings.

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.

3.1.5.4 Structural node labels

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.

3.1.6 Unspecified Aspects

The concept aspect MUST participate in the table.

Error code xbrlte:unspecifiedConceptAspect MUST be thrown if the processing software encounters a table in which the concept aspect does not participate.

The absence of any other aspect has no effect on the structural model. See also Section 6.3.1.

3.2 Definition model

The definition model is a direct representation of the contents of a table linkbase. The syntax of the linkbase provides a direct description of the definition model.

A table linkbase MUST be a valid XBRL linkbase. Violations of this requirement MUST be detected by validation against the XBRL Specification [XBRL 2.1].

Figure 4 illustrates the definition model.

Figure 4: Definition model

3.2.1 Tables

A table is defined by a <table:table> resource with at least one table-breakdown relationship. A <table:table> without any such relationships has no meaning within the scope of this specification.

The <table:table> element is related to breakdown definitions which define the shape of the table. It can also be related to filters which restrict the facts that belong to the table.

The @parentChildOrdering attribute on a table declaration may have one of two values: parent-first and 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 3.2.5.2.2.

3.2.1.1 Aspect model of the table

The @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.

Error code xbrlte:unknownAspectModel MUST be thrown if the processing software encounters an unrecognised aspect model.

3.2.1.2 Table sets

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.

3.2.2 Table filters

Tables may be associated with filters through table-filter relationships.

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.

3.2.2.1 Table-filter relationships

A table-filter relationship is a relationship between a <table:table> resource and a <variable:filter> resource expressed by an XLink arc.

A table-filter relationship is defined by an XLink arc which:

is expressed by a <table:tableFilterArc> element
has an arcrole value equal to http://xbrl.org/arcrole/PWD/2013-05-17/table-filter
has a table:table element at starting resource of the arc
has a filter at the ending resource of the arc

The arcrole value, http://xbrl.org/arcrole/PWD/2013-05-17/table-filter, is declared in the normative schema supplied with this specification.

The @complement attribute on a table-filter relationship indicates whether the filter's effect is inverted. A table-filter where the @complement attribute has a value of true uses the filter complement rather than the filter itself.

3.2.3 Axes

The axes of a table are defined by breakdown definitions.

3.2.4 Breakdowns

Breakdown definitions define breakdowns using trees of definition nodes. Breakdown definitions may also have generic labels. These label the breakdown as a whole.

A breakdown definition is represented by a <table:breakdown> element.

The <table:breakdown> element is related to trees of definition nodes which define the shape of the breakdown.

The @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 3.2.5.2.2) and overrides the value inherited from the table.

3.2.4.1 Table-breakdown relationships

A table-breakdown relationship is a relationship between a <table:table> and a <table:breakdown> element expressed by an XLink arc.

A table-breakdown relationship is defined by an XLink arc which:

is expressed by a table:tableBreakdownArc element.
has an arcrole value equal to http://xbrl.org/arcrole/PWD/2013-05-17/table-breakdown
has a table:table element at the starting resource of the arc
has a table:breakdown at the ending resource of the arc

The ordering of breakdowns is the order of the table-breakdown 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. Ordering of breakdowns is only significant for relationships that have the same value for their @axis attribute.

3.2.5 Definition nodes

A definition node is a definition of zero or more structural nodes in the structural model.

Definition nodes are represented by elements in the substitution group for the abstract <table:definitionNode> element. The following types of definition node are defined by this specification:

Rule nodes
Concept relationship nodes
Dimension relationship nodes
Aspect nodes

This section specifies syntax and semantics common to all types of definition node.

Error code xbrlte:breakdownDefinesNoAspects MUST be thrown if the processing software encounters a breakdown with no participating aspects.

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".

3.2.5.1 Extension

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.

3.2.5.2 Closed definition node

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.

Figure 5: Closed definition node model

Closed definition nodes define trees of structural nodes. Every closed definition node must contribute at least one structural node.

Error code xbrlte:closedDefinitionNodeZeroCardinality MUST be thrown if the processing software encounters a closed definition node which does not contribute at least one structural node.

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 structural node S (where 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 children of D are children of S.

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.

A closed definition node is instance-independent, and can therefore be used to define a table which can be used for both data entry and data presentation.

3.2.5.2.1 Definition-node-subtree relationships

A definition-node-subtree relationship is a relationship between elements derived from the abstract <table:closedDefinitionNode> type expressed by an XLink arc.

A definition-node-subtree relationship is defined by an XLink arc which:

is expressed by a <table:definitionNodeSubtreeArc> element
has an arcrole value equal to http://xbrl.org/arcrole/PWD/2013-05-17/definition-node-subtree
has an element derived from the <table:closedDefinitionNode> type at the starting resource of the arc
has an element derived from the <table:closedDefinitionNode> type at the ending resource of the arc

The parent of a definition node element C is the node source of a definition-node-subtree relationship whose target is the definition node element C.

The children (singular: child) of a definition node element P are the definition node elements in the target of definition-node-subtree relationships whose source is the definition node element P.

The ordering of the children is the order of the definition-node-subtree relationships, as defined by their order attributes.

3.2.5.2.2 Parent-child ordering

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 values:

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 <table:closedDefinitionNode> substitution group. Closed definition nodes that specify no value inherit a value from their parent node or, ultimately, from the parent breakdown definition or <table:table> element if either specifies a value, otherwise the default value parent-first is used.

3.2.5.3 Open definition node

An open definition node is a definition node which resolves to an open structural node.

A open definition node cannot have any children.

A table with one or more open definition nodes is an open table definition and defines an open table.

Aspect nodes are examples of open definition nodes.

3.2.5.4 Breakdown-tree relationships

A breakdown-tree relationship is a relationship between a <table:breakdown> and an element derived from the abstract <table:definitionNode> type expressed by an XLink arc.

A breakdown-tree relationship is defined by an XLink arc which:

is expressed by a table:breakdownTreeArc element.
has an arcrole value equal to http://xbrl.org/arcrole/PWD/2013-05-17/breakdown-tree
has a table:breakdown element at the starting resource of the arc
has a definition node at the ending resource of the arc

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.

3.2.6 Definition nodes (concrete)

A number of concrete definition nodes are defined by this specification.

3.2.6.1 Rule node

This section specifies semantics and syntax constraints for rule nodes.

The figure below provides a model of the rule node.

Figure 6: Rule node model

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.

A rule node may be abstract, in which case it exists to group its children and contribute a parent structural node with a common set of constraints.

Alternatively, it may be non-abstract. In which case it also represents an aggregation of its children, and contributes a roll-up node with no constraints to the structural model.

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.

3.2.6.1.1 Rule node aspect rules

The constraints of a structural node resolved from a rule node are defined by the formula aspect rules in the corresponding definition node.

The Formula specification defines aspect rules which specify output aspects.

This specification reuses this construct, but alters its interpretation in the following ways:

The aspect values defined as the output aspects (required aspect values) by the Formula specification become the aspect values of the rule node's constraints.
There is no source aspect value.
The context item when evaluating any XPath expression is undefined.

3.2.6.1.2 Rule node syntax

A rule node is represented by a <table:ruleNode> element with an optional subtree of children.

The @abstract attribute on a <table:ruleNode> element determines whether the node is abstract or not. This has implications for how it resolves (see Section 3.2.6.1.3). The default value is @abstract=false.

An abstract rule node is a rule node that is represented by a <table:ruleNode> element with @abstract=true.

A <table:ruleNode> element MAY contain one or more elements from the <formula:aspectRule> substitution group. These are used to specify aspects and aspect constraints for the node. Each <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).

The following <formula:aspectRule> features are NOT processed: @source (all rules) and @augment (unit rule).

A <table:ruleNode> MAY have <formula:aspectRule> elements that have an XPath expression. 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.]

Example 1: Rule nodes

Rule nodes Explanation

Rule nodes	Explanation
<table:ruleNode xlink:type="resource" xlink:label="parent" abstract="true"/> <table:ruleNode xlink:type="resource" xlink:label="child1"> <formula:explicitDimension dimension="eg:Geography"> <formula:member> <formula:qname> eg:Europe </formula:qname> </formula:member> </formula:explicitDimension> </table:ruleNode> <table:ruleNode xlink:type="resource" xlink:label="child2"> <formula:explicitDimension dimension="eg:Geography"> <formula:member> <formula:qname> eg:World </formula:qname> </formula:member> </formula:explicitDimension> </table:ruleNode> <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 `eg:Geography` dimension to `eg:Europe` and `eg:World`, respectively.
<table:ruleNode xlink:type="resource" xlink:label="parent" parentChildOrder="children-first"> <formula:explicitDimension dimension="eg:Geography"> <formula:member> <formula:qname> eg:World </formula:qname> </formula:member> </formula:explicitDimension> </table:ruleNode> <table:ruleNode xlink:type="resource" xlink:label="child"> <formula:explicitDimension dimension="eg:Geography"> <formula:member> <formula:qname> eg:Europe </formula:qname> </formula:member> </formula:explicitDimension> </table:ruleNode> <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 `eg:Geography` dimension to be `eg:World`, which becomes the effective constraint on the roll-up column. Meanwhile, the single child node that defines the first column specifies a different value, `eg:Europe`, for the `eg:Geography` dimension, which takes precedence over the constraint inherited from the parent node.

<table:ruleNode xlink:type="resource" xlink:label="parent" abstract="true"/>

<table:ruleNode xlink:type="resource" xlink:label="child1">

<formula:explicitDimension dimension="eg:Geography">

<formula:member>

<formula:qname>

eg:Europe

</formula:qname>

</formula:member>

</formula:explicitDimension>

</table:ruleNode>

<table:ruleNode xlink:type="resource" xlink:label="child2">

<formula:explicitDimension dimension="eg:Geography">

<formula:member>

<formula:qname>

eg:World

</formula:qname>

</formula:member>

</formula:explicitDimension>

</table:ruleNode>

<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 eg:Geography dimension to eg:Europe and eg:World, respectively.

<table:ruleNode xlink:type="resource" xlink:label="parent" parentChildOrder="children-first">

<formula:explicitDimension dimension="eg:Geography">

<formula:member>

<formula:qname>

eg:World

</formula:qname>

</formula:member>

</formula:explicitDimension>

</table:ruleNode>

<table:ruleNode xlink:type="resource" xlink:label="child">

<formula:explicitDimension dimension="eg:Geography">

<formula:member>

<formula:qname>

eg:Europe

</formula:qname>

</formula:member>

</formula:explicitDimension>

</table:ruleNode>

<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 eg:Geography dimension to be eg:World, which becomes the effective constraint on the roll-up column. Meanwhile, the single child node that defines the first column specifies a different value, eg:Europe, for the eg:Geography dimension, which takes precedence over the constraint inherited from the parent node.

3.2.6.1.3 Rule node resolution

Each rule node resolves to either one or two structural nodes, as shown in Figure 7 and Figure 8, respectively.

A rule node, D, always contributes a single structural node, S, as a child of the structural node to which the parent of D resolves.

All children of D resolve to children of S.

The constraints attached to the structural node S are those defined by the aspect rules attached to rule node D.

If D is an abstract rule node, it resolves to the single structural node, S, as shown in Figure 7.

An abstract rule node MUST have at least one child.

Error code xbrlte:abstractRuleNodeNoChildren MUST be thrown if the processing software encounters an abstract rule node with no children.

If D is a non-abstract rule node with at least one child, it additionally contributes a single roll-up node, R, as a child of S, as shown in Figure 8.

Placement of the roll-up node is determined by the effective value of the rule node's @parentChildOrder attribute, as described in Section 3.2.5.2.2: if the @parentChildOrder attribute has a value of parent-first, the roll-up node is the first child; if the @parentChildOrder attribute has a value of children-first, the roll-up node is the last child. Figure 8 shows the latter case.

Figure 7: Resolution of an abstract rule node

Figure 8: Resolution of a non-abstract rule node

The roll-up node contributes no constraints, so the constraints of its ancestors apply.

3.2.6.1.4 Rule node labels

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).

Rule nodes are associated with rule node labels, by XLink arcs which link the rule node definition to:

a generic label, using the http://xbrl.org/arcrole/2008/element-label arcrole
a generic reference, using the http://xbrl.org/arcrole/2008/element-reference arcrole

A processor MAY add labels to the structural nodes contributed during resolution as described in Section 3.1.5.4.

3.2.6.2 Relationship nodes

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.

Figure 9: Relationship node model

A relationship node is a closed definition node expressed in terms of concept and dimensional relationship networks.

A relationship node defines a tree walk of part of a concept or dimensional network.

The tree walk defined by a relationship node unambiguously identifies part of a 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 order of 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 using the @parentChildOrder attribute on the <table:conceptRelationshipNode> element or <table:dimensionRelationshipNode> 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 3.2.1.2. [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.

Where not stated, no XBRL 2.1 Base Set or Dimensional Relationship Set filtering is performed for link and arc QNames. [Jon Siddle: This needs clarifying]

Relationship nodes do not have any labels. A processor SHOULD add labels to the structural nodes contributed during resolution as described in Section 3.1.5.4.

3.2.6.2.1 Relationship binding

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 (such as @preferredLabel or @weight). For definition nodes that include the -or-self suffix on the <formulaAxis> element[Jon Siddle: I think "in the value of the axis element" would be clearer], the @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.

3.2.6.2.2 Relationship source

A relationship node MAY specify a relationship source concept (by <relationshipSource> QName or <relationshipSourceExpression> QName expression).

An element <formulaAxis> or <formulaAxisExpression> specifies whether the source concept is included in the rendered concepts, by the -or-self suffix on the <formulaAxis> element or <formulaAxisExpression> result. If the suffix -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 formulaAxis is described in Table 2 below.

Table 2: Relationship node behaviour

`formulaAxis`	`relationshipSource`	Behaviour
when the suffix `-or-self` is present	omitted or `xfi:root`	The root relationships are equivalent to a virtual root source concept that has the root concepts of the network as children.
when the suffix `-or-self` is present	present	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 `@name` variable does not have a bound relationship object (it is an empty sequence for the source objects).
when the suffix `-or-self` is not present	omitted or `xfi:root`	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.
when the suffix `-or-self` is not present	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 @conceptname attribute, 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).

3.2.6.2.3 Relationship node syntax

A relationship node is represented by a <table:conceptRelationshipNode> aspect rule for XBRL 2.1 base set (concept to concept) relationship nodes, and by a <table:dimensionRelationshipNode> aspect rule for dimensional relationship nodes.

Both of these relationship node elements have:

Zero or more <table:relationshipSource> or <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.
An optional <formulaAxis> or <formulaAxisExpression> suffix, -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-self is 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.
An optional <table:generations> integer or <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.
A <table:linkrole> or <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 instance's <xbrli:xbrl> element. XPath expressions MAY refer to parameters and XPath variables that MAY be assigned by other nodes, such as other relationship nodes @name and @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 xfi:facts-in-instance.

3.2.6.2.4 Concept-relationship node

A concept relationship node is a relationship node which defines a tree walk of a concept network.

For a <formulaAxis> element, valid values correspond to those for xfi:concept-relationships filters (descendant, child, ancestor, parent, sibling or sibling-or-descendant) [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:

The arc role, as specified by a <table:arcrole> or <table:arcroleExpression> element, which is respectively a non-empty URI or an expression (xl:nonEmptyURI).
The link element name, as specified by a <table:linkname> or <table:linknameExpression> element, which is respectively QNames or QName expressions (xs:QName).
The arc element name as specified by a <table:arcname> or <table:arcnameExpression> element, which is respectively QNames or QName expressions (xs:QName).

As described in Section 3.2.6.2, 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:

The arc role MUST be specified (for example, parent-child). [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. ]
The source element, link role, link element name, and arc element name, are individually optional, but MUST be specified as required to unambiguously identify the network and starting point.

The concept aspect is the only participating aspect in a concept relationship node. Note that the concept aspect applies to all concepts of the DTS (including any dimension concepts).

3.2.6.2.5 Dimension-relationship node

A dimension relationship node is a relationship node which defines a tree walk of a dimensional network.

For a <formulaAxis> element, valid values correspond to those for df:explicitDimension filters (descendant or child) [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:

A dimension relationship node can specify a constraint on the dimension domains and their members, as specified by the <table:dimension> or <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.
The networks follow @targetRole and 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 3.2.6.2, 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:

A dimension-relationship node MUST specify the QName of at least one relationship source.
- Error code xbrlte:missingRelationshipSource MUST be thrown if the processing software encounters a dimension-relationship node that specifies no relationship sources.
- It is not an error if the specified relationship source is not the QName of a concept in the DTS.
A dimension-relationship node MUST specify the link role of the network in which to start navigating the DRS if the starting concept participates in multiple networks.
- Error code xbrlte:ambiguousInferredLinkrole MUST be thrown if the processing software encounters a dimension-relationship node for which the starting link role cannot be uniquely inferred from the starting concept.
A dimension-relationship node MUST specify the QName of the participating dimension if it cannot be identified unambiguously from the starting concept and link role. If a dimension-relationship node specifies a QName for the dimension and a concept with the specified QName exists in the DTS, it MUST be an explicit dimension item.
- Error code xbrlte:missingDimensionForDimensionRelationshipNode MUST be thrown if the processing software encounters a dimension-relationship node that does not specify a dimension and for which the dimension cannot be unambiguously identified from the starting concept and link role.
- Error code xbrlte:invalidExplicitDimensionQName MUST be thrown if the processing software encounters a dimension-relationship node that specifies a QName for the dimension which exists in the DTS, but is not an explicit dimension.
- It is not an error if the specified QName is not the QName of a concept in the DTS.

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.

A single dimension aspect is the only participating aspect in a dimension relationship node.

3.2.6.3 Aspect node

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.

Figure 10: Aspect node model

3.2.6.3.1 Aspect node aspect constraints

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 that aspect.

3.2.6.3.2 Partitioning

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 @includeUnreportedValue is true and the contributing 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.

The contributing facts for the aspect node are the facts in the fact source for the table, filtered according to the formula filters associated with the aspect node.

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.

Example 2: Effect of filtering non-participating aspects

If the facts present in the fact source as as follows:

Concept Aspect	Period Aspect	Fact Value
Profit	2011	100
Assets	2012	100
Profit	2013	100
Assets	2013	200

Given the following definition of aspect node and associated filter:

<table:aspectNode xlink:type="resource" xlink:label="periodNode" id="periodNode">

<table:periodAspect/>

</table:aspectNode>

<cf:conceptName xlink:type="resource" xlink:label="conceptFilter">

<cf:concept>

<cf:qname>

eg:profit

</cf:qname>

</cf:concept>

</cf:conceptName>

<table:aspectNodeFilterArc xlink:from="periodNode" xlink:to="conceptFilter" xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/PWD/2013-05-17/aspect-node-filter"/>

The resulting table would look like this (assuming a suitable definition of the y-axis with concept as a participating aspect):

	2013	2011
Profit	100	100
Assets	100	(unreported)

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.

3.2.6.3.3 Aspect node labels

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.

3.2.6.3.4 Aspect node syntax

An aspect node is represented by a <table:aspectNode> 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 <table:aspectSpec> substitution group specifies the participating aspect of the aspect node.

The <table:conceptAspect> , <table:entityIdentifierAspect> , <table:periodAspect> , <table:unitAspect> elements specify the concept, entityIdentifier, period and unit aspects respectively.

The <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.

3.2.6.3.4.1 Aspect-node-filter relationships

An aspect-node-filter relationship is a relationship between an <table:aspectNode> and a <variable:filter> expressed by an XLink arc.

To declare a aspect-node-filter relationship an XLink arc MUST:

have an arcrole value equal to http://xbrl.org/arcrole/PWD/2013-05-17/aspect-node-filter
have a <table:aspectNode> element at the starting resource of the arc
have a filter at the ending 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 this specification.

A complemented aspect-node-filter relationship is a aspect-node-filter relationship that is expressed by an arc with a @complement attribute that has a value of true.

An aspectNode with a complemented aspect-node-filter relationship to a filter uses the filter complement in its implied XPath expression.

3.2.6.3.4.1.1 Aspect-node-filter arcs

An aspect-node-filter arc is expressed by the <table:aspectNodeFilterArc> element.

The syntax for the <table:aspectNodeFilterArc> element is defined by the normative schema supplied with this specification.

3.2.7 Variable references

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.

3.3 Layout model

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.

The process of producing a layout from a structural model is described in Section 6.3.

[Victor Morilla: This chapter has become obsolete with the introduction of chapter 7]

[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.]

3.3.1 Layout tables

A layout table represents an arrangement of selected XBRL facts following a matrix layout in a Cartesian space with x, y and z axes.

3.3.2 Axes

An axis defines an ordered mapping of XBRL fact space onto a line.

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.

The x-axis SHOULD be interpreted as a horizontal arrangement of columns in a table. Columns MAY be laid out from left to right, or right to left, according to the language conventions.
The y-axis SHOULD be interpreted as a vertical progression of rows in a table. Rows SHOULD be laid out from top to bottom.
The z-axis MAY be interpreted as multiple two-dimensional tables and MAY be laid out on a two-dimensional display by presenting each table in series or by supplying controls for the user to select the data to be presented.

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.

3.3.3 Axis headers

Axis headers describe axes to communicate heading information about the cells at the intersections of rows and columns and to impart semantic structure to the table.

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).

3.3.4 Header cell labels

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:

If it has a single concept constraint or explicit dimension constraint, the processor SHOULD select a single label associated with that concept in the DTS.
If it has a single unit, entity-identifier, period or typed dimension constraint, the processor SHOULD use a text representation of the constraint's aspect value.

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.

3.3.5 Cells

Cells are located at the intersections of rows and columns and act as containers for XBRL facts.

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.

4 Table source

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).

5 Infosets

This specification defines two "infosets", which are serialisations of two of the three models.

5.1 Structural infoset

[Jon Siddle: Needs specification]

5.2 Layout infoset

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.

5.2.1 Table sets

Each table set is represented by a <tablemodel:tableSet> element, as a child of the root <tablemodel:tableModel> element. An infoset may contain any number of table sets.

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 single <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.

5.2.2 Tables

A table is represented by a <tablemodel:table> element.

A <tablemodel:table> element must have as its children:

exactly one <tablemodel:cells> element describing the contents of the table cells
one or more <tablemodel:headers> elements describing the headers for each axis of the table.

An optional @label attribute on the <tablemodel:table> element is used to label each table.

5.2.3 Axis headers

The headers for an axis are declared by a <tablemodel:headers> element.

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 x, y and z. Only one <tablemodel:headers> element may be associated with each axis for a given table.

A <tablemodel:header> element contains a sequence of <tablemodel:label> elements. Each <tablemodel:label> element describes the label associated with a single header cell. These are ordered according to the natural direction of ordering in the rendered table.

The @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 "explicit".

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 @rollup attribute with a value of true.

5.2.4 Table cells

Each cell is represented by a single <tablemodel:cell> element.

The <tablemodel:cell> elements are arranged into nested <tablemodel:cells> elements.

Each <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 <tablemodel:cell> elements is contained in a <tablemodel:cells> element, which represents a one dimensional sequence of cells along a single axis, indicated by the @axis attribute on the containing <tablemodel:cells> element. The position of each cell along the indicated axis is determined by its position within the containing <tablemodel:cells> element.

The most nested <tablemodel:cells> elements may each be contained in another <tablemodel:cells> element, which represents a two dimensional slice of cells along another axis. These in turn may be nested inside a single <tablemodel:cells> element, representing a three dimensional slice (of which there is only one).

In this way, each level of nesting addresses a more specific part of the data. The position of a child element C within a <tablemodel:cells> element P with an @axis attribute value of A determines the position along axis A of all cells which are descendants of C (or C itself).

A <tablemodel:cells> element contains either a sequence of <tablemodel:cell> elements, or a sequence of nested <tablemodel:cells> elements. Each <tablemodel:cells> element must specify (using the required @axis attribute) the axis along which its contained slices or cells are arranged.

The value of the @axis attribute on a <tablemodel:cells> element must be one of the three axes defined by this specification: x, y and z. All 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 ancestors.

The text content of a <tablemodel:cell> 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.]

6 Processing model (definition of functions)

6.1 Compilation

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.

6.2 Resolution

Resolution is the process of building a structural model from the definition model.

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.

6.2.1 Table set resolution

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 3.2.1.2.

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.

6.2.2 Table resolution

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.

6.2.2.1 Expansion

The process of resolving a single definition node into one or more structural nodes is called expansion. The output of this process is called the expansion.

Where a definition node D expands to a single structural node S, the parent of S is the structural node to which the parent of D expands. If D has no parent, S has no parent. Note that the parent of D cannot 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 3.2.5.2).
Where a definition node D expands to a tree of structural nodes, with structural node S being the root of this tree, the parent of S is the structural node to which the parent of D resolves. If D has no parent, S has no parent. The non-root structural nodes in the expansion are arranged as described in the specification of the definition node.
Where a definition node D expands to a list of structural nodes S₁..S_n, the parent of every structural node S₁..S_n is the structural node to which the parent of D resolves. If D has no parent, S₁..S_n have 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.

6.2.2.2 Height Balancing

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.

6.3 Layout

The layout process takes the structural model and a fact source and produces a layout.

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).]

A fact source is a container for XBRL facts. An XBRL instance is an example of a fact source.

A fact source need not have a serialisation. It MAY exist only in memory, or be dynamically created on demand. A fact source may be modifiable, to support data entry.

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.

6.3.1 Under-specified tables

6.3.1.1 Dimensional Aspects

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.

6.3.1.2 Non-Dimensional Aspects

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 6.3.1.3

6.3.1.3 Multiple Values in a Cell

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:

by displaying the most appropriate fact or facts. For example, locale may be used to select the fact with the most appropriate language or unit.
by displaying a single fact, where the values are consistent,
by producing separate instances of the table for each value of an unconstrained aspect. For example, if period is unspecified, it may be desirable to produce a rendered table for each period present in the instance.
by providing user interface controls for the user to select which facts are displayed. For example, the user may be presented with a choice of entity identifiers present in the instance, and shown a table containing only the facts relating to the selected entity.

6.3.2 Projection of multiple breakdowns onto an axis

Multiple breakdowns may be associated with a single table axis. Breakdowns on an axis are according to the @order attributes of the table-breakdown relationships linking their definitions to that of the table.

Projection is the process of combining two or more independent breakdowns into a single effective breakdown for display on a single axis.

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 effective breakdown for an axis is the result of projecting all of the individual breakdowns associated with that axis.

Figure 11: Projection of two breakdowns onto an axis

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 (B 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.

Figure 12: Projection involving a more complicated breakdown

6.3.3 Headers

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.

6.3.4 Elimination

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.

Processors MAY perform elimination when laying out a table for data presentation. Processors MUST NOT perform elimination when laying out a table for data entry.

6.3.5 Partitioning

[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).]

Partitioning is the process of expanding an open structural node during the layout process.

This partitioning depends on the fact source (possibly a dynamic fact source used for data entry), but is otherwise similar to expansion

Aspects that participate in partitioning are referred to as partitioning aspects.

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.

See Section 3.2.6.3.2 for a description of partitioning for filter nodes.

6.3.6 Layout for data presentation

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).

6.3.7 Layout for data entry

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.

Appendix A Normative schemas

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:

While any schema is the most current RECOMMENDED version and until it is superseded by any additional errata corrections a non-normative version will reside on the web in the directory 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.
A non-normative version of each schema as corrected by any update to the RECOMMENDATION will be archived in perpetuity on the web in a directory that will contain a unique identification indicating the date of the update.

A.1 Table linkbase schema (table.xsd)

<link:definition>

breakdown used on the axes of a table

</link:definition>

<link:usedOn>

table:tableBreakdownArc

</link:usedOn>

</link:arcroleType>

<link:definition>

root node of a breakdown tree

</link:definition>

<link:usedOn>

table:breakdownTreeArc

</link:usedOn>

</link:arcroleType>

<link:definition>

filter applied to table

</link:definition>

<link:usedOn>

table:tableFilterArc

</link:usedOn>

</link:arcroleType>

</appinfo>

</annotation>

</extension>

</complexContent>

</complexType>

</extension>

</complexContent>

</complexType>

Attributes for ordinates (axes that act as ordinates).

</documentation>

</annotation>

</attributeGroup>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

</extension>

</complexContent>

</complexType>

</restriction>

</complexContent>

</complexType>

</extension>

</simpleContent>

</complexType>

</restriction>

</simpleType>

</extension>

</complexContent>

</complexType>

</element>

</complexContent>

</complexType>

</element>

</extension>

</complexContent>

</complexType>

</element>

<link:definition>

arc between a parent and child definition node.

</link:definition>

<link:usedOn>

table:definitionNodeSubtreeArc

</link:usedOn>

</link:arcroleType>

</appinfo>

</annotation>

</complexContent>

</complexType>

</element>

</sequence>

</extension>

</complexContent>

</complexType>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

</choice>

</choice>

</choice>

</choice>

</choice>

</choice>

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

</choice>

</choice>

</choice>

</choice>

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</restriction>

</simpleType>

</union>

</simpleType>

<link:definition>

filter applied to filter node

</link:definition>

<link:usedOn>

table:aspectNodeFilterArc

</link:usedOn>

</link:arcroleType>

</appinfo>

</annotation>

</sequence>

</extension>

</complexContent>

</complexType>

</extension>

</complexContent>

</complexType>

</element>

</schema>

A.2 Layout infoset schema (tablemodel.xsd)

This is the top level element representing a table model containing zero or more table sets, each derived from a single table definition in the table linkbase.

</documentation>

</annotation>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

This type represents the headers defined by a table set. A single table set defines 1 or more tables, and these headers describe the relationship between these tables.

</documentation>

</annotation>

</sequence>

</complexType>

This type represents a table. A table has fixed axes as described by the table headers.

</documentation>

</annotation>

</sequence>

</choice>

</complexType>

This type represents the headers for a single axis (x, y or z) of a table.

</documentation>

</annotation>

</sequence>

</complexType>

This type represents groups levels in a set of headers for a single axis, for labelling purposes.

</documentation>

</annotation>

</sequence>

</complexType>

This type represents a single level in a set of headers for a single axis. It contains a series of header labels.

</documentation>

</annotation>

</sequence>

</complexType>

</sequence>

</complexType>

</extension>

</simpleContent>

</complexType>

</sequence>

</complexType>

</restriction>

</simpleType>

</restriction>

</simpleType>

</union>

</simpleType>

</sequence>

</complexType>

</choice>

</complexType>

</sequence>

</complexType>

</attributeGroup>

</schema>

Appendix B References

CONCEPT RELATION FILTERS: XBRL International Inc.. "XBRL Concept Relation Filters 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/conceptRelationFilters/REC-2011-10-24/conceptRelationFilters-REC-2011-10-24.html)
DIMENSION FILTERS: XBRL International Inc.. "XBRL Dimension Filters 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/dimensionFilters/CR-2008-12-31/dimensionFilters-CR-2008-12-31.html)
DIMENSIONS: XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
FORMULA: XBRL International Inc.. "XBRL Formulae 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/formula/CR-2008-12-31/formula-CR-2008-12-31.html)
GENERIC LABELS: XBRL International Inc.. "XBRL Generic Labels 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/genericLabels/REC-2009-06-22/genericLabels-REC-2009-06-22.html)
GENERIC REFERENCES: XBRL International Inc.. "XBRL Generic References 1.0 (Public Working Draft)"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/genericReferences/REC-2009-06-22/genericReferences-REC-2009-06-22.html)
VARIABLES: XBRL International Inc.. "XBRL Variables 1.0"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/variables/REC-2009-06-22/variables-REC-2009-06-22.html)
XBRL 2.1: XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2012-01-25"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/specification/xbrl-recommendation-2003-12-31+corrected-errata-2012-01-25.htm)
XLINK: W3C (World Wide Web Consortium). "XML Linking Language (XLink) Version 1.0"
Steve DeRose, Eve Maler, and David Orchard.
(See http://www.w3.org/TR/xlink/)
XML NAMES: W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)
XPATH 2.0: W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
(See http://www.w3.org/TR/xpath20/)
XPATH AND XQUERY FUNCTIONS: W3C (World Wide Web Consortium). "XQuery 1.0 and XPath 2.0 Functions and Operators"
Ashok Malhotra, Jim Melton, and Norman Walsh.
(See http://www.w3.org/TR/xpath-functions/)

Appendix C Intellectual property status (non-normative)

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).

Appendix D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix E Document history (non-normative)

Date	Author	Details
01 October 2011	Herm Fischer	Initial draft
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 (using `@order` across arcroles)
01 August 2012	Herm Fischer	Editorial updates suggested by WG e-mails from Shogo Ohyama : (a) Filter axes wording in paragraph 1 of Section 3.2.6.3.1. (b) Filter axes with XPath expressions dependent on other ordinate values by variable names, in Section 3.2.6.3.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.

Appendix F Errata corrections in this document

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.

Table Linkbase 1.0

Public Working Draft 17 May 2013

Status

Abstract

Comments

Table of Contents

Appendices

Tables

Figures

Examples

Definitions

Error codes

1 Introduction

1.1 Relationship to other work

1.2 Namespaces and namespace prefixes

1.3 Document conventions (non-normative)

1.4 XPath usage

2 Uses

3 Models

3.1 Structural model

3.1.1 Tables

3.1.2 Table sets

3.1.3 Constraints

3.1.4 Breakdowns

3.1.4.1 Breakdown labels

3.1.4.2 Uniform depth

3.1.4.3 Aspect Constraints

3.1.4.4 Closed breakdowns

3.1.4.5 Open breakdowns

3.1.5 Structural nodes

3.1.5.1 Closed structural nodes

3.1.5.2 Open structural nodes

3.1.5.3 Roll-up nodes

3.1.5.4 Structural node labels

3.1.6 Unspecified Aspects

3.2 Definition model

3.2.1 Tables

3.2.1.1 Aspect model of the table

3.2.1.2 Table sets

3.2.2 Table filters

3.2.2.1 Table-filter relationships

3.2.3 Axes

3.2.4 Breakdowns

3.2.4.1 Table-breakdown relationships

3.2.5 Definition nodes

3.2.5.1 Extension

3.2.5.2 Closed definition node

3.2.5.2.1 Definition-node-subtree relationships

3.2.5.2.2 Parent-child ordering

3.2.5.3 Open definition node

3.2.5.4 Breakdown-tree relationships

3.2.6 Definition nodes (concrete)

3.2.6.1 Rule node

3.2.6.1.1 Rule node aspect rules

3.2.6.1.2 Rule node syntax

3.2.6.1.3 Rule node resolution

3.2.6.1.4 Rule node labels

3.2.6.2 Relationship nodes

3.2.6.2.1 Relationship binding

3.2.6.2.2 Relationship source

3.2.6.2.3 Relationship node syntax

3.2.6.2.4 Concept-relationship node

3.2.6.2.5 Dimension-relationship node

3.2.6.3 Aspect node

3.2.6.3.1 Aspect node aspect constraints

3.2.6.3.2 Partitioning

3.2.6.3.3 Aspect node labels

3.2.6.3.4 Aspect node syntax

3.2.6.3.4.1 Aspect-node-filter relationships

3.2.6.3.4.1.1 Aspect-node-filter arcs

3.2.7 Variable references

3.3 Layout model

3.3.1 Layout tables

3.3.2 Axes

3.3.3 Axis headers

3.3.4 Header cell labels

3.3.5 Cells

4 Table source

5 Infosets

5.1 Structural infoset