Table Linkbase 1.0

Public Working Draft 16 January 2013

Copyright © 2011, 2012, 2013 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/table-linkbase/PWD-2013-01-16/table-linkbase-PWD-2013-01-16.html>
Editors:
Herm Fischer, Mark V Systems <fischer@markv.com>
Victor Morilla, Banco de España <victor.morilla@bde.es>
Jon Siddle, CoreFiling <js@corefiling.com>
Contributors:
Geoff Shuetrim, Galexy Pty. <geoff@galexy.com>
Masatomo Goto, Fujitsu Ltd. <mg@jp.fujitsu.com>
Roland Hommes, RHOCON <roland@rhocon.nl>
Takahide Muramoto, Fujitsu <taka.muramoto@jp.fujitsu.com>
Bartosz Ochocki, BRAG <bartosz.ochocki@br-ag.eu>
Shogo Ohyama, Fujitsu Ltd. <ohyama.shogo@jp.fujitsu.com>
Hugh Wallis, Standard Dimensions <hugh@standarddimensions.com>
Paul Warren, CoreFiling <pdw@corefiling.com>

Status

Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to rendering-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

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.

Comments

1 Victor Morilla:I'm not sure this is a good example. Since we are talking about the constraints in a table, the resolution process has already taken place. Maybe a better example would be a selection of the concepts identified by a certain relationship network in the DTS
2 Victor Morilla:Should this rule be limited to constraints defined in terms of aspects values?
3 Victor Morilla:This should be marked as a definition
4 Jon Siddle:This needs renaming (aspectModelMismatch? tableAspectModelMismatch?)
5 Jon Siddle:This name is ok, but would opposingAxisAspectClash be better?
6 Victor Morilla:This should be renamed to breakdownsAspectClash. I don't understand the 'opposing' proposal. The error is meant to be raised if two different breakdowns constraint the same aspect. Even if two breakdowns are associated to the same axis, it is a conflict
7 Victor Morilla:The first sentence is a bit imprecise: what cannot be determined statically is the value of the aspects. But the aspects should be (after the resolution has taken place)
8 Victor Morilla:This is not normative text, this is just a hint for tool implementations. So, we should not use rfc-MUST
9 Victor Morilla:We should extend this definition and explain, in the definition model, how each concrete node may provide labels and references in its corresponding elements in the structural model. A label in the structural model might have its origin in a generic label in the case of a ruleNode or in a standard label in the case of the node relationship breakdown. But at the structural model it is just a label. Thus, the structural model provides an abstraction layer for the syntax used in the definition model for labels
10 Victor Morilla:We should change this by a reference to the aspect models defined by the variable specification
11 Victor Morilla:We should avoid the term implied XPath expression
12 Jon Siddle:This is way too fuzzy. How do you validate if such a means has been provided? I'm not sure it's necessary given the way each node is defined, but if a certain definition node type makes this error possible, we should probably note it specifically for that node (and then we can say exactly what needs to be validated). This also needs renaming (undefinedAspectValue?)
13 Herm Fischer:The root ordinate on each axis may, but should not be required, to identify values for an aspect. Many examples will have the root ordinate abstract as a parent for child ordinates.
14 Herm Fischer:I think this should say every non-root ordinate. For example, z-axis may have no aspects.
15 Jon Siddle:I'm not sure if this is meant for an axis, breakdown or node. In any case I think this should just be allowed (e.g. roll-up nodes, DTS visualisation, etc).
16 Victor Morilla:This refers to old axes, now breakdowns. So, it should be changed to breakdownDefinesNoAspects or maybe breakdownConstraintsNoAspects
17 Victor Morilla:I'd remove the non-abstract term here. It is a bit confusing and abstract XML elements cannot appear anyway
18 Jon Siddle:I'm not sure this section is helpful. It certainly isn't sufficient - in fact any new definition node requires a full description of how it resolves.
19 Jon Siddle:I don't think we want to allow this; new definition nodes should be restricted to produce the same structural nodes as existing definition nodes
20 Roland Hommes:The list above is only addressing generic label, reference, message. Not 2.1 label and reference resource roles
21 Herm Fischer:Commented out reference to 2.1 labels, which only pertain to concepts, and aren't used on resources, such as the elements of the table linkbase. In cases of relationship axes, where concepts and dimensions have concept labels, the axis-message is required to determine the appropriate label and label role, due to the usual need to support start, end, total, and negated labels according to the linkbase at hand.
22 Victor Morilla:There is an inconsistency with the way messages and generic labels are defined. We should review this part. When it comes to generic labels in ruleNodes, several labels can be defined: which label should be used for actual rendering is not defined in the table linkbase (it is defined in the rendering linkbase or at application level). However, messages are specified as the text to be used directly for rendering.
23 Victor Morilla:This paragraph is not necessary
24 Jon Siddle:Surely we can't just redefine what aspect rules mean? We're either using the formula specification or we're not.
25 Herm Fischer:Note to reviewers: please indicate if there is a use case for labels to be constrained to specific link roles, such as to match the composition of a table.
26 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).
27 Roland Hommes:An XPath expression on an instance that does not exists will result in a high level XPath error message.
28 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.
29 Victor Morilla:We should say non-abstract and non-terminal. Terminal nodes (I mean leaves) contribute with a single node
30 Jon Siddle: As discussed within the WG, this ambiguity MUST be resolved by the specification. There are two high-level solutions: define this to be an error in all cases, or define inference behaviour which resolves the ambiguity in all cases. The working group has not yet reached agreement on this issue.
31 Jon Siddle: I think that this should be an error in all cases. Our suggestion is to include the following text: Error code xbrlte:ambiguousNonAbstractRuleNode MUST be thrown if the processing software encounters a non-abstract rule node with descendants which have participating aspects which are not participating aspects of either the non-abstract rule node or one of its ancestors. This prevents the undesirable situation where descendants of the non-abstract rule node specify a certain aspect, but the value for that aspect representing an aggregate (for example, the default dimension member) is not specified. This is undesirable because the result would be a roll-up column containing not only the aggregate facts but also containing the facts in the columns it was intended to roll-up.
32 Victor Morilla:This section should be removed. We should discuss more this issue. There are simple use cases where the situation defined here as an error makes perfect sense. For instance, let's say we want to represent a certain concept (total incomes). In an extension we add a breakdown by two or three countries (uk, es, ...). Countries are represented by a typed dimension with the two letter iso code. The non-abstract non-terminal node does not define an aspect (country dimension) defined by children nodes. Rather than this specific constraint for rule nodes, we should define a more general rule in the structural model: if a terminal node (or any of its parent nodes in the breakdown) does not address an aspect constrained by other sibling nodes in the breakdown, its default value will be assumed. If no default value is defined for that aspect, an error should be raised. The default value for typed dimensions and explicit dimensions with no default member is the absence of that dimension. The default value for explicit dimensions with default member is the default member. For other aspects, the default value is not defined.
33 Victor Morilla:This paragraph should be replaced by a reference to section 3.2.7
34 Jon Siddle:This needs clarifying
35 Jon Siddle:I think "in the value of the axis element" would be clearer
36 Roland Hommes:What does it mean when table:generations is both optional and must be ignored?
37 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?
38 Jon Siddle:I think it should be an error if generation is present and not 1 for these axes
39 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.
40 Roland Hommes:Errorcode if table:dimension refers to a QName that is not a dimension concept?
41 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.
42 Jon Siddle:The composition node is surely redundant given that a rule node can define such a composition?
43 Victor Morilla:I think we agreed on a previous meeting to remove this kind of node
44 Jon Siddle: This could do with clarification. It's not obvious what the items below mean, or how this relates to the tuple node.
45 Jon Siddle:Broken reference removed. Sorting isn't mentioned by the XPATH2 spec - what was intended here?
46 Jon Siddle:The context item should be the aspect value, not the fact.
47 Jon Siddle:I think it should only ever produce an aspect value
48 Jon Siddle:I don't think this should be allowed at all.
49 Jon Siddle:This needs clarifying
50 Jon Siddle:What should a conforming processor do instead of evaluating these expressions when asked to render a table with no standard input instance?
51 Jon Siddle:Surely since the selection node specifies an aspect, adding values dynamically may be allowed?
52 Paul Warren:This needs proper specification, ideally by reference to a common section defining the behaviour.
53 Jon Siddle:We should rename this to drop the "covered" and reflect the fact that the matching method is encoded in the enumeration
54 Jon Siddle:Surely this should be an error, since a selection node must have a participating aspect.
55 Jon Siddle:I think this could be worded more clearly, or omitted. I don't think it's necessary to repeat the conditions about satisfying all constraints at an intersection (and it isn't clear that "preceding" is sufficient here). It seems to be saying that a fact will correspond to a constraint of the filter node if it matches the filter and satisfies the conditions of the other axes. If so, the latter point is redundant.
56 Jon Siddle:I don't think this is correct. There's nothing in the formula spec that describes a partitioning similar to the way we split a filter's results into columns, other than the idea of implicit filtering (in which case this is the opposite of covering).
57 Jon Siddle:This needs renaming (filterCoversNoAspect?)
58 Jon Siddle:Do we have a use-case for not partitioning by a constrained aspect?
59 Jon Siddle:I'm confused by this. A filter (definition) node can't have any children, and I don't know what "tandem" means in this context. More fundamentally, is the suggestion that a filter node contributes a tree of nodes, not just a flat list? That's not specified, and from what I understand of the possible graphs of formula filters, it's not well defined for tables. I think this is going to add a lot of complexity, so we need to go back to use cases and explain this more thoroughly.
60 Roland Hommes:Where did the specific use for a typed dimension come from? Probably the whole filter node header is meant for situations where labels may not be provided because the instance contains 'raw xml' only supplied by the reporter.
61 :There are many examples of typed dimensions, not only in current Eurofiling tables, but most other situations where persion or department names, numbers, and such other stuff are in the raw xml. This is why an XPath expression (via a message) is required for a typed dimension to be in a header. The simple case is that the typed dimension is a string or number that is used without any formatting or tricks, but I'm also seeing country codes (that need lookup to be country names), etc.
62 Jon Siddle:How should circular dependencies be handled?
63 Herm Fischer:Need an error message (to be compatible to formula).
64 Jon Siddle:What should be done instead of evaluating the expressions when rendering a table in such a case?
65 Paul Warren:See comment above about definition vs validation.
66 Victor Morilla:This chapter has become obsolete with the introduction of chapter 7
67 Victor Morilla:An alternative definition would ensure that the table linkbase is not instance specific. A possible alternative would describe a table as representing selected facts from a "universe of facts"
68 Victor Morilla:A table represents facts. Only facts. That does not mean that we can render fact related information using formatting rules; but formatting rules are not part of this specification. Moreover, a market tool could render the value and its unit, provide a popup window to display footnotes and let the user decide, using application options, whether to represent other properties. An open question is whether it is necessary to force users to provide all those details in a taxonomy.
69 Hugh Wallis:The above comments will be resolved following feedback from within the Working Group and from the public
70 Paul Warren:(referring to previous wording) The meaning of the phrase "the data" is unclear. I think this should probably be phrased as "the set of cells", and we should introduce a definition for "cell".
71 Herm Fischer:The data is more than just cells, it also includes stuff for headers. It could be stuff that isn't physically rendered by headers or cells but some tool mechanisms provide it like roll-over pop-ups or dialogs for html text blocks, footnotes, links within text blocks, <a href=...>, images, videos, charts and graphs, etc. I agree cell needs to be defined in the next editing.
72 Jon Siddle:This is ambiguous. Should siblings blindly honour the @order attribute or is there some form of alignment implied by the above?
73 Jon Siddle:When a non-abstract parent has additional labels, what should these align with? The conformance suite seems to have conflicting examples, possibly using the ELR to align the additional labels? If this is the desired behaviour it isn't stated in this specification.
74 Jon Siddle:Resolving equal @order attributes using document order is inconsistent with the XBRL 2.1 specification which states "If multiple siblings in the hierarchy have the same order attribute value, the presentation order of those siblings is application dependent."
75 Jon Siddle:This is all different now; we need to rewrite this in terms of additional headers and new arcroles
76 Jon Siddle:Needs specification
77 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.
78 Jon Siddle:But tuple nodes are rule nodes which are closed definition nodes, so they can't rely on facts. If we need tuple nodes to depend on facts, they must be open nodes.
79 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).
80 Victor Morilla:We should elaborate this a bit more. There might be cases where the taxonomy author defines a table and wants that table to discard any fact that includes dimensions not specified by the constraints of the table.
81 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).

Table of Contents

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 Closed breakdowns
3.1.4.2 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.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 Definition nodes
3.2.4.1 Closed definition node
3.2.4.1.1 Definition-node-subtree relationships
3.2.4.1.2 Parent-child ordering
3.2.4.2 Open definition node
3.2.4.2.1 Definition node requirements
3.2.4.3 Table-breakdown relationships
3.2.5 Definition node labels
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 headers
3.2.6.1.3 Rule node syntax
3.2.6.1.4 Rule node resolution
3.2.6.1.5 Ambiguous non-abstract rule nodes
3.2.6.1.6 Tuple node
3.2.6.1.6.1 Tuple node aspect rules
3.2.6.1.6.1.1 Tuple-content relationships
3.2.6.1.6.2 Tuple node syntax
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 Composition node
3.2.6.3.1 Composition node headers
3.2.6.3.2 Composition-node syntax
3.2.6.4 Selection node
3.2.6.4.1 Selection node ordering
3.2.6.4.2 Selection
3.2.6.4.3 Partitioning
3.2.6.4.4 Headers
3.2.6.4.5 Selection node syntax
3.2.6.5 Filter node
3.2.6.5.1 Filter node aspect constraints
3.2.6.5.2 Partitioning
3.2.6.5.3 Filter node headers
3.2.6.5.4 Filter node syntax
3.2.6.5.4.1 filter-node-filter relationships
3.2.6.5.4.1.1 filter-node-filter arcs
3.2.7 Variable references
3.3 Rendering model
3.3.1 Rendering tables
3.3.2 Axes
3.3.3 Axis headers
3.3.4 Cells
4 Labels
5 Table source
6 Infosets
6.1 Structural infoset
6.2 Rendering infoset
6.2.1 Table sets
6.2.2 Tables
6.2.3 Axis headers
6.2.4 Table cells
7 Processing model (definition of functions)
7.1 Compilation
7.2 Resolution
7.2.1 Table set resolution
7.2.2 Table resolution
7.2.2.1 Expansion
7.3 Rendering
7.3.1 Under-specified tables
7.3.2 Projection of multiple breakdowns onto an axis
7.3.3 Headers
7.3.4 Elimination
7.3.5 Partitioning
7.3.6 Rendering for data presentation
7.3.7 Rendering for data entry

Appendices

A Normative schemas
A.1 Table linkbase schema (table.xsd)
A.2 Rendering infoset schema (tablemodel.xsd)
B References
C Intellectual property status (non-normative)
D Acknowledgements (non-normative)
E Document history (non-normative)
F Errata corrections in this document

Tables

1 Namespaces and namespace prefixes
2 Relationship node behaviour

Figures

1 Structural model
2 Structural model example
3 Structural model example table
4 Definition model
5 Closed definition node model
6 Rule node model
7 Resolution of an abstract rule node
8 Resolution of a non-abstract rule node
9 Tuple axis model
10 Relationship node model
11 Composition node model
12 Selection node model
13 Filter node model
14 Cartesian product of two breakdowns

Examples

1 Use of a message to select the preferred label for a concept
2 Rule nodes

Definitions

abstract
axis
axis headers
breakdown
breakdown definition
cardinality
cell
children
closed breakdown
closed definition node
closed structural node
closed table
compilation
complemented filter-node-filter relationship
composition node
concept relationship node
constraint
contribute
coordinate
covering filter-node-filter relationship
data entry
data presentation
definition model
definition node
definition node label
definition-node-subtree relationship
dimension relationship node
domain of a table
elimination
expansion
fact belonging to a table
fact source
filter node
filter-node-filter arc
filter-node-filter relationship
matches
open breakdown
open definition node
open structural node
open table
open table definition
parent
participating aspect
participating in a table
partitioning
partitioning aspect
projection
relationship node
rendering
rendering model
rendering process
rendering table
resoultion
roll-up node
rule node
selection
selection node
shape of a table
structural model
structural node
table
table set
table-breakdown relationship
table-filter relationship
the expansion
tree walk
tuple node
tuple-content relationship
unpopulated

Error codes

xbrlte:abstractRuleNodeNoChildren
xbrlte:ambiguousNonAbstractRuleNode
xbrlte:aspectValueNotDefinedByOrdinate
xbrlte:axisAspectClash
xbrlte:axisAspectModelMismatch
xbrlte:axisDefinesNoAspects
xbrlte:axisFilterCoversNoAspects
xbrlte:closedDefinitionNodeZeroCardinality
xbrlte:unknownAspectModel


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-01-16/table
xbrlte http://xbrl.org/PWD/2013-01-16/table/error
tablemodel http://xbrl.org/PWD/2013-01-16/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

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:

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

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 of the facts eligible to be presented or entered in a table cell.

Each row or column of a table is associated with a set of one or more constraints. Facts must satisfy all of the combined constraints of the intersecting rows and columns to be rendered or entered in a cell.

A common form of constraint is the restriction of a given aspect to a single value, but other types of constraint (e.g. selection of different networks in the DTS) are possible. [Victor Morilla: I'm not sure this is a good example. Since we are talking about the constraints in a table, the resolution process has already taken place. Maybe a better example would be a selection of the concepts identified by a certain relationship network in the DTS]

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 path through the breakdown tree from root to leaf defines a set of constraints to be satisfied by facts in the corresponding rows/columns of the table. For constraints defined in terms of aspect values, if conflicting constraints (different aspect values for the same aspect) are present in this path, the aspect value closest to the leaf is used. [Victor Morilla: Should this rule be limited to constraints defined in terms of aspects values?]

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. [Victor Morilla: This should be marked as a definition]

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:axisAspectModelMismatch 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). [Jon Siddle: This needs renaming (aspectModelMismatch? tableAspectModelMismatch?)]

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 such breakdowns would be meaningless).

Error code xbrlte:axisAspectClash MUST be thrown if the processing software encounters two breakdowns in a table that address common aspects. [Jon Siddle: This name is ok, but would opposingAxisAspectClash be better?][Victor Morilla: This should be renamed to breakdownsAspectClash. I don't understand the 'opposing' proposal. The error is meant to be raised if two different breakdowns constraint the same aspect. Even if two breakdowns are associated to the same axis, it is a conflict]

For a single breakdown in isolation, the leaf nodes of the breakdown tree each correspond to a single row or column in the rendered table. Branch nodes correspond to headers in the rendered table that span the headers corresponding to the descendant nodes.

Figure 2 illustrates the (partial) structural model corresponding to the table in Figure 3. Facts are broken down by two dimensions: Product and Geography. The constraints associated with each node are not shown; the two nodes with rollUp=true explicitly constrain the Geography dimension to its default value.

Figure 2: Structural model example

Figure 3: Structural model example table

The aspects participating in the breakdowns of a table cannot always be statically determined. All aspects for a definition using only closed definition nodes can be determined during the resolution process. Aspects for a definition containing open definition nodes cannot be fully determined until expansion occurs as part of the rendering process. [Victor Morilla: The first sentence is a bit imprecise: what cannot be determined statically is the value of the aspects. But the aspects should be (after the resolution has taken place)]

Every breakdown is associated with one of the axes defined by the rendering model. Several breakdowns may be projected onto a single axis in the rendered table, as described in Section 7.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.1 Closed breakdowns

A closed breakdown is defined as a breakdown whose sequence of constraints can be determined independently of the facts to be presented.

Access to the DTS of an instance (either an existing instance or one to be created from data entered by the user) may be required to determine the constraints for a closed breakdown, but access to the instance itself is not required.

3.1.4.2 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 MUST 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. [Victor Morilla: This is not normative text, this is just a hint for tool implementations. So, we should not use rfc-MUST]

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 that does not depend on the facts in the instance.

A closed structural node has been fully expanded during resolution, and is not further expanded during rendering.

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.

During rendering, an open structural node is expanded. An open structural node may define an ordering for its expansion.

An example is a node that lists each period used in an instance. For data presentation, knowledge of the facts to be presented is required to enumerate the periods. For data entry, open nodes describe dynamic regions of a table, into which a variable number of periods can be entered based on user input. While an ordering for the periods can be known in advance, the actual periods are not.

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 structural node may be associated with one or more labels, for the purpose of contributing axis headers to the rendered table. A label may involve XPath expressions that evaluate to the text to be used as a header. These expressions may reference variables bound during the expansion process, which are substituted with their bound values prior to evaluating the expressions. The scope of variables that may be legally referenced by a structural node label consists of variables bound during the expansion of the definition node that defined the node to which the label is attached or its parent definition nodes, in addition to global parameters. [Victor Morilla: We should extend this definition and explain, in the definition model, how each concrete node may provide labels and references in its corresponding elements in the structural model. A label in the structural model might have its origin in a generic label in the case of a ruleNode or in a standard label in the case of the node relationship breakdown. But at the structural model it is just a label. Thus, the structural model provides an abstraction layer for the syntax used in the definition model for labels]

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 trees of definition nodes 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.4.1.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. Recognised aspect models include the dimensional and non-dimensional aspect models. [Victor Morilla: We should change this by a reference to the aspect models defined by the variable specification]

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:

The arcrole value, http://xbrl.org/arcrole/PWD/2013-01-16/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 has the filter complement in its implied XPath expression rather than the filter itself. [Victor Morilla: We should avoid the term implied XPath expression]

3.2.3 Axes

The axes of a table are defined by breakdown definitions, which are trees of definition nodes.

3.2.4 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
  • Tuple nodes
  • Concept relationship nodes
  • Dimension relationship nodes
  • Composition nodes
  • Selection nodes
  • Filter nodes

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

Error code xbrlte:aspectValueNotDefinedByOrdinate MUST be thrown if the processing software encounters a definition which specifies one or more aspects, but does not specify or provide a means for identifying values for one or more of those aspects. [Jon Siddle: This is way too fuzzy. How do you validate if such a means has been provided? I'm not sure it's necessary given the way each node is defined, but if a certain definition node type makes this error possible, we should probably note it specifically for that node (and then we can say exactly what needs to be validated). This also needs renaming (undefinedAspectValue?)]

[Herm Fischer: The root ordinate on each axis may, but should not be required, to identify values for an aspect. Many examples will have the root ordinate abstract as a parent for child ordinates.]

Error code xbrlte:axisDefinesNoAspects MUST be thrown if the processing software encounters one axis with no aspects.

[Herm Fischer: I think this should say every non-root ordinate. For example, z-axis may have no aspects.]

[Jon Siddle: I'm not sure if this is meant for an axis, breakdown or node. In any case I think this should just be allowed (e.g. roll-up nodes, DTS visualisation, etc).]

[Victor Morilla: This refers to old axes, now breakdowns. So, it should be changed to breakdownDefinesNoAspects or maybe breakdownConstraintsNoAspects]

Definition nodes contribute nodes to the structural model through the resolution process (described in Section 7.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.4.1 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 may not have children.

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

3.2.4.1.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:

[Victor Morilla: I'd remove the non-abstract term here. It is a bit confusing and abstract XML elements cannot appear anyway]

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.4.1.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 rendered as the first child of its parent node. This is the default value.
  • children-first: the roll-up node MUST be rendered as the last child of its parent node.

This attribute may be specified on the <table:table> element or any element in the <table:closedDefinitionNode> substitution group. Closed definition nodes that specify no value inherit a value from a parent node or, ultimately, from the <table:table> element.

3.2.4.2 Open definition node

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

A open definition node may not have any children.

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

Filter nodes and selection nodes are examples of open definition nodes.

3.2.4.2.1 Definition node requirements

[Jon Siddle: I'm not sure this section is helpful. It certainly isn't sufficient - in fact any new definition node requires a full description of how it resolves.]

New types of definition node may be defined by later specifications. Any such new definition node MUST meet the following requirements:

  • A definition of the participating aspect(s)
  • The context item used when evaluating XPath expressions allowed by the definition node (if any).
  • Rendering transformations if other than string representation of value (e.g., scaling, numeric transformation, specific number or date formatting). [Jon Siddle: I don't think we want to allow this; new definition nodes should be restricted to produce the same structural nodes as existing definition nodes]

3.2.4.3 Table-breakdown relationships

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

The <table:definitionNode> referenced by the arc identifies the root of the breakdown.

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

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 node labels

Definition node labels associate static or dynamic text with a definition node.

Typically, such text will be rendered in the column and row headers.

Definition nodes can be associated with one or more definition node labels, by XLink arcs which link the axis node definition to:

[Roland Hommes: The list above is only addressing generic label, reference, message. Not 2.1 label and reference resource roles ][Herm Fischer: Commented out reference to 2.1 labels, which only pertain to concepts, and aren't used on resources, such as the elements of the table linkbase. In cases of relationship axes, where concepts and dimensions have concept labels, the axis-message is required to determine the appropriate label and label role, due to the usual need to support start, end, total, and negated labels according to the linkbase at hand.]

For definition nodes that expand to a sequence or tree of concepts or dimension members, labels may be selected from the taxonomy using a generic message with an XPath expression that makes use of xfi-functions and references variables bound to the current concept, member or relationship during expansion of the node. For example, a concept-relationship node based on a presentation network might use xfi-functions to select the preferred label for each concept, as illustrated in Example 1 below.

[Victor Morilla: There is an inconsistency with the way messages and generic labels are defined. We should review this part. When it comes to generic labels in ruleNodes, several labels can be defined: which label should be used for actual rendering is not defined in the table linkbase (it is defined in the rendering linkbase or at application level). However, messages are specified as the text to be used directly for rendering. ]

Example 1: Use of a message to select the preferred label for a concept

A concept-relationship node binds each traversed relationship to the conceptRel variable and each target concept to the conceptQname variable.

<table:conceptRelationshipNode xlink:type="resource" xlink:label="crNode" name="conceptRel" conceptname="conceptQname">
<table:arcrole>
http://www.xbrl.org/2003/arcrole/parent-child
</table:arcrole>
</table:conceptRelationshipNode>

A message uses the xfi:relationship-attribute function to get the preferred label role from the relationship and the xfi:concept-label to get the desired label for the concept.

<gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-message" xlink:from="crNode" xlink:to="crMsg"/>
<msg:message xlink:type="resource" xlink:role="http://www.xbrl.org/2010/role/message" xlink:label="crMsg" xml:lang="en">
xfi:concept-label( $conceptQname, '', xfi:relationship-attribute( $conceptRel, QName('', 'preferredlabel') ), 'en' )
</msg:message>

Note how the same concept may appear several time in the tree with different labels.

References may include URLs pointing to web-based material. These MAY be rendered as hyperlinks to provide the user with direct access to the referenced material. [Victor Morilla: This paragraph is not necessary]

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

In the context of the Formula specification, aspect rules specify aspect values that the output fact is required to match. In this specification, aspect rules will be used to specify the aspect values that facts that correspond to that node MUST match.

[Jon Siddle: Surely we can't just redefine what aspect rules mean? We're either using the formula specification or we're not.]

The aspect rules of a rule node represented by a rule node element use as source aspect values (SAVs) of (the required) aspect rules of its ancestor ruleNode elements, but it MAY specify aspect values that override these inherited aspect values. Where the formula specification makes reference to input instances for SAV and output instances for required aspect value (RAV), in this specification SAV become RAV when a source instance of existing facts is used to populate a table.

3.2.6.1.2 Rule node headers

As described before, the headers of the definition node are represented by the set of rule node elements, their subtrees, and their rules. As the definition node rule element is represented using XLink resources in a generic linkbase, they MAY be associated to generic labels, references or messages. These labels, messages and references SHOULD be used for the headers by a rendering engine. Labels, messages, and references are used in the normal manner of such linkbases, ignoring the link role labels and references.

[Herm Fischer: Note to reviewers: please indicate if there is a use case for labels to be constrained to specific link roles, such as to match the composition of a table.]

3.2.6.1.3 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.4). 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 2: Rule nodes

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-01-16/definition-node-subtree" xlink:from="parent" xlink:to="child1" order="1"/>
<table:definitionNodeSubtreeArc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/PWD/2013-01-16/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-01-16/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.4 Rule node resolution

Each rule noderesolves 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 abstractrule 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, it additionally contributes a single roll-up node, R, as a child of S, as shown in Figure 8.

[Victor Morilla: We should say non-abstract and non-terminal. Terminal nodes (I mean leaves) contribute with a single node]

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.4.1.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.5 Ambiguous non-abstract rule nodes

If every aspect participating in the definition nodes descendent from a non-abstract rule node is also a participating aspect in the rule node itself or one of its ancestors in the breakdown, the aspect values associated with the contributed roll-up node are unambiguous.

If one or more aspects participating in the definition nodes descendent from a non-abstract rule node are not also participating aspects in the rule node itself or one of its ancestors, the aspect values associated with the contributed roll-up are ambiguous.

[Jon Siddle: As discussed within the WG, this ambiguity MUST be resolved by the specification. There are two high-level solutions: define this to be an error in all cases, or define inference behaviour which resolves the ambiguity in all cases. The working group has not yet reached agreement on this issue. ]

[Jon Siddle: I think that this should be an error in all cases. Our suggestion is to include the following text: Error code xbrlte:ambiguousNonAbstractRuleNode MUST be thrown if the processing software encounters a non-abstract rule node with descendants which have participating aspects which are not participating aspects of either the non-abstract rule node or one of its ancestors. This prevents the undesirable situation where descendants of the non-abstract rule node specify a certain aspect, but the value for that aspect representing an aggregate (for example, the default dimension member) is not specified. This is undesirable because the result would be a roll-up column containing not only the aggregate facts but also containing the facts in the columns it was intended to roll-up. ]

[Victor Morilla: This section should be removed. We should discuss more this issue. There are simple use cases where the situation defined here as an error makes perfect sense. For instance, let's say we want to represent a certain concept (total incomes). In an extension we add a breakdown by two or three countries (uk, es, ...). Countries are represented by a typed dimension with the two letter iso code. The non-abstract non-terminal node does not define an aspect (country dimension) defined by children nodes. Rather than this specific constraint for rule nodes, we should define a more general rule in the structural model: if a terminal node (or any of its parent nodes in the breakdown) does not address an aspect constrained by other sibling nodes in the breakdown, its default value will be assumed. If no default value is defined for that aspect, an error should be raised. The default value for typed dimensions and explicit dimensions with no default member is the absence of that dimension. The default value for explicit dimensions with default member is the default member. For other aspects, the default value is not defined. ]

3.2.6.1.6 Tuple node

This section specifies semantics and syntax constraints for tuple nodes. Tuple nodes provide an implementation of rule nodes, in a manner specialized to support creation of tuples for axis nodes (such as rows on a table), where the tuple created serves as a location aspect for opposite-axis facts (column specified fact items) that are contained in the tuple.

The figure below provides a model of the tuple node and the tuple:location aspect it facilitates on rule nodes for contained facts.

Figure 9: Tuple axis model

A tuple node is an implementation of a rule node whose constraint is expressed in terms of a rule node that corresponds to matching of, or generation of, a tuple. The tuple node MAY have rules representing specific aspects, e.g., tuple concept and location aspect (if it is nested in another tuple).

3.2.6.1.6.1 Tuple node aspect rules

The rules of a tuple node specialize (subclass) the rule node by adding a name attribute and provision for tuple contents. The @name attribute binds the tuple matched or generated to an XPath variable name that can be used by a tuple:location aspect in the rule node for any contained tuple facts (items or tuples). Furthermore, a tuple node does not contribute any aspects to opposite axes or tuple-content related axes, so that the concept rule and location aspects of the tuple node don't conflict with opposite-axis and tuple-content rules for tuple contents. (For example, if y-axis rows represent tuples, and x-axis columns represent fact items in the row tuple, then the tuple node concept and location rules do not interfere with the x-axis column fact items. The columnnar items situate themselves in the row tuples by a tuple:location aspect with a source attribute naming the tuple node name).

Content of tuples matched or produced by tupleNode rules can be located by other nodes referencing the tupleNode name, in a <tuple:location> aspect rule, on other breakdowns or in nested nodes on the same breakdown, or can be matched or produced to be located in non-rendered (off-axis) tuple contents by tuple-concept relationships to such off-axis rule nodes.

3.2.6.1.6.1.1 Tuple-content relationships

A tuple-content relationship is a relationship between elements derived from the <table:tupleNode> type and elements derived from thev <table:ruleNode> type expressed by an XLink arc.

A tuple-content relationship is defined by an XLink arc which:

The facts specified by the ending resource rule nodes DO NOT contribute to the definition node that they were related from (either in terms of aspects or any other manner), but MAY be nested tupleNode elements specifying by name nested tuples that contribute a referable location aspect.

3.2.6.1.6.2 Tuple node syntax

The tupleNode inherits the syntax description of the ruleNode.

A @name attribute defines an referable variable that can be used as the source attribute of a <tuple:location> aspect rule and for any other XPath purposes.

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 10 below provides a model of relationship nodes.

Figure 10: 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 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]

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
descendant-or-self
child-or-self
ancestor-or-self
parent-or-self
sibling-or-self
sibling-or-descendant-or-self
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.
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).
descendant
child
ancestor
parent
sibling
sibling-or-descendant
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.
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. The definition nodes correspond to xfi:concept-relationships filter nodes (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.
  • 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.

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.

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:

  • The starting concept MUST be identified.
  • The starting link role MUST be identified if the primary item participates in multiple networks.
  • The dimension MUST be identified explicitly if the relationship source doesn't unambiguously identify it.

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 Composition node

[Jon Siddle: The composition node is surely redundant given that a rule node can define such a composition?]

[Victor Morilla: I think we agreed on a previous meeting to remove this kind of node]

This section specifies semantics and syntax constraints for composition nodes.

The figure below provides a model of the composition node.

Figure 11: Composition node model

A composition node is a closed definition node which resolves to a single structural node with no aspect constraints.

Although it provides no constraints of its own, it still provides a way to define a composition of its child definition nodes (as described in Section 3.2.4.1).

3.2.6.3.1 Composition node headers

Unlike a rule node, a composition node does not contribute to any headers, although its children can still contribute to the headers. Processors MUST ignore any associated definition node label (such as generic labels, references or messages).

3.2.6.3.2 Composition-node syntax

A compositionNode is represented by a <table:compositionNode> element with a subtree of <table:closedDefinitionNode> elements connected by an http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-subtree relationship.

3.2.6.4 Selection node

A selection node is an open definition node which resolves to a sequence of structural nodes which constrain fact space to selected aspect values for a single aspect.

A selection node specifies an aspect to constrain, and an XPath expression that evaluates to a sequence of aspect values for that aspect.

Each aspect value in the sequence maps to a structural node during resolution. Each such structural node constrains fact space to match against the associated aspect value.

The figure below provides a model of the selection node.

Figure 12: Selection node model

Selection nodes are used to define aspect values in terms of an XPath expression which may use xfi functions to access information about the fact source.

With appropriate usage of xfi functions, selection nodes can be used to define:

  • A selection of the extended link roles used in an instance (e.g., balance sheet and document information for an instance representing a balance sheet with accompanying company document information)
  • Tuples in a Global Ledger instance document[Jon Siddle: This could do with clarification. It's not obvious what the items below mean, or how this relates to the tuple node. ]
    • Starting balance and ending balance; or
    • A selection of account codes that have transactions; or
    • A set of transaction items for a selected account code.
  • Contexts in an instance
  • Contexts defined in an instance, but not referenced by any fact
3.2.6.4.1 Selection node ordering

The XPath selection expression produces a sequence. Although most XPath operations result in sequences that are in source instance document node order, sequences may be sorted (such as account code or name, using custom functions such as described in [Jon Siddle: Broken reference removed. Sorting isn't mentioned by the XPATH2 spec - what was intended here?]).

3.2.6.4.2 Selection

A selection yields a sequence of aspect values for a single aspect.

The associated aspect value for each structural node can be bound to a variable, which may be referenced by other definition nodes subject to certain conditions. See Section 3.2.7 for the restrictions on variable references.

The sequence of aspect values may be determined by an evaluation of an expression, or by matching aspect values for candidate facts against a predicate. See Section 3.2.6.4.5 for more details.

If it is dependent on the context item (".") then the context item is a fact or empty sequence produced by other nodes (and the selection node is then dependent on any other node that would result in binding of the context item to a fact, and MUST be processed after such other node).

[Jon Siddle: The context item should be the aspect value, not the fact.]

A select expression MAY produce an aspect of a fact (such as a attribute value or any other XPath navigation from the context item or from a named variable which has a fact value). The select expression MAY produce an aspect of the fact based on xfi functions and expression (such as a period end date or unit, or a footnote (or footnotes sequence), or any other data derived by table lookup (such as from an fn:doc loaded table)).

[Jon Siddle: I think it should only ever produce an aspect value]

Select expression results that are XML nodes in an instance document, attributes of relationship elements, or nodes in an fn:doc() have the post-schema-validation typed value of the node (as with formula processing).

[Jon Siddle: I don't think this should be allowed at all. ]

A select expression for an aspect other than location MUST have an atomic value (such as a datetime of the midnight of an instant period for a period-instant aspect). Using xml node values of time-less period xbrli:instant elements will not have the right datetime for an aspect value, use of the xfi functions is recommended instead. A select expression for the location aspect MUST have a node value.

[Jon Siddle: This needs clarifying]

Select expressions are not evaluated when rendering a table with no standard input instance or one with no facts.

[Jon Siddle: What should a conforming processor do instead of evaluating these expressions when asked to render a table with no standard input instance?][Jon Siddle: Surely since the selection node specifies an aspect, adding values dynamically may be allowed?]

3.2.6.4.3 Partitioning

Selection nodes produce a rendering node for each aspect value in the selection. Each rendering node constrains the selection's aspect to the selection's aspect value.

3.2.6.4.4 Headers

As with other definition nodes; labels, references or messages MAY be used.

[Paul Warren: This needs proper specification, ideally by reference to a common section defining the behaviour.]

3.2.6.4.5 Selection node syntax

<table:selectionNode> is an element with @name, @select and @coveredAspect attributes.

The @name attribute behaves like a variable name, so that the selection value can be referred to by XPath construct $name.

The @coveredAspect attribute identifies the participating aspect for which the @select expression produces values, and a method for matching the aspect value.

Its type is a union of an enumeration (identifying an aspect and matching method) and QName (identifying a dimension aspect). [Jon Siddle: We should rename this to drop the "covered" and reflect the fact that the matching method is encoded in the enumeration]

The @select attribute specifies an XPath expression that evaluates to a sequence of aspect values for the aspect identified by the @coveredAspect attribute.

The possible values of the @coveredAspect attribute which identify non-dimensional aspects are:

  • concept. The concept aspect is the participating aspect and the value of the @select is a QName which matches a fact's QName.
  • entity-identifier. The entity identifier aspect is the participating aspect and the value of @select is an entity identifier (token) value which matches a fact's entity identifier.
  • period-start. The period aspect is the participating aspect and the value of @select is a dateTime (union) value which matches a fact's start.
  • period-end. The period aspect is the participating aspect and the value of @select is a dateTime (union) value which matches a fact's end only.
  • period-instant. The period aspect is the participating aspect and the value of @select is a dateTime (union) value which matches a fact's instant only.
  • period-instant-end. The period aspect is the participating aspect and the value of @select is a dateTime (union) value which matches a fact's instant or end.
  • unit. The unit aspect is the participating aspect and the value of @select is a QName which matches a single-measure unit.

If the value of @coveredAspect identifies a dimension by QName then it specifies that the identified dimension is the participating aspect. The @select expression (if present) specifies a predicate with an aspect value (of the specified dimension aspect) as the subject of the predicate.

If the value of @coveredAspect is a QName value that does not identify a dimension, there is no participating aspect, but this is not an error.[Jon Siddle: Surely this should be an error, since a selection node must have a participating aspect.]

3.2.6.5 Filter node

This section specifies semantics and syntax constraints for filter nodes. Filter nodes provide an implementation of open definition nodes based on the use of filters.

The figure below provides a model of the filter node.

Figure 13: Filter node model

A filter node is an implementation of open definition nodes expressed in terms of variable filters. Those variable filters are associated to the axis through filter-node-filter relationships.

3.2.6.5.1 Filter node aspect constraints

A fact corresponds to one of the constraints of a filter node if it satisfies every filter associated to its own axis, for that subset of the facts that satisfy or correspond with preceding definition nodes on the same axis (if any such preceding definition nodes), and that satisfy the constraints of the other axes, and all other constraints for the cell being rendered.

[Jon Siddle: I think this could be worded more clearly, or omitted. I don't think it's necessary to repeat the conditions about satisfying all constraints at an intersection (and it isn't clear that "preceding" is sufficient here). It seems to be saying that a fact will correspond to a constraint of the filter node if it matches the filter and satisfies the conditions of the other axes. If so, the latter point is redundant.]

The aspects participating in a filter node are the aspects covered by its filters. (The concept of aspect-covering as noted in the variables specification [VARIABLES] applies to implicit filtering for binding facts to variables of a variable set, and in this specification applies to designating the aspects covered by an axis, for determination of axis aspect coverage conflicts.) [Jon Siddle: I don't think this is correct. There's nothing in the formula spec that describes a partitioning similar to the way we split a filter's results into columns, other than the idea of implicit filtering (in which case this is the opposite of covering).]

An axis filter cannot be associated to filters that do not cover an aspect.

Error code xbrlte:axisFilterCoversNoAspects MUST be thrown if the processing software encounters a filter in a filter node that covers no aspects. [Jon Siddle: This needs renaming (filterCoversNoAspect?) ]

3.2.6.5.2 Partitioning

During the partitioning phase of the rendering process, a filter node expands to a number of rendering nodes.

Filter nodes use formula filters to constrain facts and to partition the constrained facts into columns or rows.

Each filter node may involve multiple formula filters and the formula filters may involve multiple aspects, each of which may or may not be partitioning[Jon Siddle: Do we have a use-case for not partitioning by a constrained aspect?].

The facts constrained by the filter node are partitioned by the partitioning aspects, and each partition corresponds to a set of constraints for further breakdown (nested structural breakdown nodes, defined either by nested or tandem definition model nodes). [Jon Siddle: I'm confused by this. A filter (definition) node can't have any children, and I don't know what "tandem" means in this context. More fundamentally, is the suggestion that a filter node contributes a tree of nodes, not just a flat list? That's not specified, and from what I understand of the possible graphs of formula filters, it's not well defined for tables. I think this is going to add a lot of complexity, so we need to go back to use cases and explain this more thoroughly.]

3.2.6.5.3 Filter node headers

Headers of the filter node are represented by the set of XLink resources [XLINK] in a generic linkbase [GENERIC LINKS]. They can be associated to generic labels, references or messages. These generic labels, references and messages SHOULD be used as labels and references of the headers by a rendering engine. Labels, messages, and references are used in the normal manner of such linkbases, ignoring the link role labels and references.

Usually a filter node provides a dynamically determined set of columns for which a static label association does not make sense, but instead a message may be associated. Then a typed dimension could use the message's formatting capabilities. The message context item is bound to one (or more) facts that meet the filter constraints. Thus the message could provide a desired label for a dimension qname value, a typed dimension contents, or period.

[Roland Hommes: Where did the specific use for a typed dimension come from? Probably the whole filter node header is meant for situations where labels may not be provided because the instance contains 'raw xml' only supplied by the reporter. ][: There are many examples of typed dimensions, not only in current Eurofiling tables, but most other situations where persion or department names, numbers, and such other stuff are in the raw xml. This is why an XPath expression (via a message) is required for a typed dimension to be in a header. The simple case is that the typed dimension is a string or number that is used without any formatting or tricks, but I'm also seeing country codes (that need lookup to be country names), etc.]

3.2.6.5.4 Filter node syntax

A filter node is represented by a <table:filterNode> element with one or more <variable:filter> resources related by axis filter arc relationships.

The <table:filterNode> filters may have XPath expressions. The context item for each XPath expression is the fact bound to each axis, or the selection node result when applicable (when bound to coordinates of a cell). XPath expressions may refer to parameters and selection nodes by name, when in effect.

If the filter node has an XPath expression that is dependent on other nodes by variable names that are bound to those nodes (such as by a @name attribute of another node), then it is dependent on the other (named) node and MUST be processed after the other node is bound to a fact or value.

[Jon Siddle: How should circular dependencies be handled? ]

[Herm Fischer: Need an error message (to be compatible to formula).]

Filters, and any of their XPath expressions, are not evaluated when rendering a table with no standard input instance or one with no facts.

[Jon Siddle: What should be done instead of evaluating the expressions when rendering a table in such a case?]

3.2.6.5.4.1 filter-node-filter relationships

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

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

The arcrole value, http://xbrl.org/arcrole/PWD/2013-01-16/axis/filter-node-filter, is declared in the normative schema supplied with this specification.

Axis-filter relationships MUST be expressed by filter-node-filter arcs. Violations of this requirement MUST be detected by validation against the XBRL Specification [XBRL 2.1].

[Paul Warren: See comment above about definition vs validation.]

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

A filterNode with a complemented filter-node-filter relationship to a filter uses the filter complement in its implied XPath expression rather than the filter itself.

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

If a filter is related to a variable by a variable-filter relationship, that filter only covers aspects of the facts being filtered if the variable-filter relationship is covering .

3.2.6.5.4.1.1 filter-node-filter arcs

A filter-node-filter arc is expressed by the <table:filterNodeFilterArc> element.

The syntax for the <variable:filterNodeFilterArc> 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 Rendering model

The rendering model directly represents the layout and content of each table in a rendering, 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 rendering from a structural model is described in Section 7.3.

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

3.3.1 Rendering tables

A rendering table represents selected XBRL facts and an arrangement of values derived from those facts following a matrix layout in a Cartesian space with x, y and zaxes.

[Victor Morilla: An alternative definition would ensure that the table linkbase is not instance specific. A possible alternative would describe a table as representing selected facts from a "universe of facts"]

[Victor Morilla: A table represents facts. Only facts. That does not mean that we can render fact related information using formatting rules; but formatting rules are not part of this specification. Moreover, a market tool could render the value and its unit, provide a popup window to display footnotes and let the user decide, using application options, whether to represent other properties. An open question is whether it is necessary to force users to provide all those details in a taxonomy. ]

[Hugh Wallis: The above comments will be resolved following feedback from within the Working Group and from the public]

[Paul Warren: (referring to previous wording) The meaning of the phrase "the data" is unclear. I think this should probably be phrased as "the set of cells", and we should introduce a definition for "cell".][Herm Fischer: The data is more than just cells, it also includes stuff for headers. It could be stuff that isn't physically rendered by headers or cells but some tool mechanisms provide it like roll-over pop-ups or dialogs for html text blocks, footnotes, links within text blocks, <a href=...>, images, videos, charts and graphs, etc. I agree cell needs to be defined in the next editing.]

3.3.2 Axes

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

This specification describes three axes, labelled 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 rendered 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 rendered from top to bottom.
  • The z-axis MAY be interpreted as multiple two-dimensional tables and MAY be rendered 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 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 7.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 label 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 labels 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 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 Labels

Use of multiple labels, references, and messages as axis headers MAY include references, header codes and hyperlinks, which render in additional row header or column header cells, in order of their effective relationships XLink @order attribute (independent of arc roles), and document order among multiple resources of the same relationship or equal-order relationships. If there is at least one location on an axis with such additional labels, header positions are reserved for all other locations on that axis (e.g., if one x-axis column has a reference label, all neighboring column headers will have a reference axis header, even if empty).

[Jon Siddle: This is ambiguous. Should siblings blindly honour the @order attribute or is there some form of alignment implied by the above?][Jon Siddle: When a non-abstract parent has additional labels, what should these align with? The conformance suite seems to have conflicting examples, possibly using the ELR to align the additional labels? If this is the desired behaviour it isn't stated in this specification.][Jon Siddle: Resolving equal @order attributes using document order is inconsistent with the XBRL 2.1 specification which states "If multiple siblings in the hierarchy have the same order attribute value, the presentation order of those siblings is application dependent."][Jon Siddle: This is all different now; we need to rewrite this in terms of additional headers and new arcroles]

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

6 Infosets

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

6.1 Structural infoset

[Jon Siddle: Needs specification]

6.2 Rendering infoset

The rendering infoset is an XML serialisation of the rendering 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 rendered, as outlined below.

The rendering infoset is used by the conformance suite to compare renderings produced by tools implementing this specification to those expected from a conformant processor.

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

6.2.2 Tables

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

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

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

6.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 at least one <tablemodel:label> element. 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.

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.

6.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 slice (a row or column) 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.

Each most nested <tablemodel:cells> element may 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.]

7 Processing model (definition of functions)

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

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

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

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

7.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.4.1).
  • 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 S1..Sn, the parent of every structural node S1..Sn is the structural node to which the parent of D resolves. If D has no parent, S1..Sn 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.

tuple nodes require the presence of tuples to perform tuple breakdowns resulting in structural model tuple nodes. [Jon Siddle: But tuple nodes are rule nodes which are closed definition nodes, so they can't rely on facts. If we need tuple nodes to depend on facts, they must be open nodes.]

7.3 Rendering

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

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 rendering process may be interactive. Examples of interactive rendering 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 rendering is a result of the rendering process.

7.3.1 Under-specified tables

During rendering, multiple facts may be found which match a single cell. In this case, the rendering behaviour is application dependent. Applications MAY choose to handle this in one of the following ways:

  • by displaying the most appropriate fact or facts based on, e.g., locale,
  • by displaying a single fact, where the values are consistent,
  • by rendering separate copies of the table for each value of an unconstrained aspect,
  • by providing controls for the user to select which facts are displayed.

[Victor Morilla: We should elaborate this a bit more. There might be cases where the taxonomy author defines a table and wants that table to discard any fact that includes dimensions not specified by the constraints of the table. ]

7.3.2 Projection of multiple breakdowns onto an axis

Projection is the process of combining the constraints from two or more independent breakdowns into a single sequence of constraints for display on a single axis.

Multiple breakdowns associated with the same axis are combined by taking the Cartesian product of the individual lists of constraints. The combined constraints are ordered lexicographically, as illustrated in Figure 14: each constraint from the first breakdown is taken, in order, in combination with each constraint from the second breakdown, also in order. This process is repeated for further breakdowns.

Figure 14: Cartesian product of two breakdowns

7.3.3 Headers

As part of the rendering 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 7.3.2.

Axis headers are constructed from labels attached to nodes in the structural model. Each breakdown contributes a number of rows/columns of labels to the header for the axis with which it is associated. Each level of a breakdown tree contributes a single row/column of labels to the header, with each structural node contributing zero or more labels. 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.

Labels may include messages that include XPath expressions, which may reference variables bound during the expansion process. The process of creating headers involves evaluating these expressions.

7.3.4 Elimination

Elimination is the process of eliminating unpopulated rows and columns to produce a more compact table.

An unpopulated row or column of a table is one whose constraints match no facts when populating the table.

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

7.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 rendering 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 rendering node for each value of each partitioning aspect it defines. Every open definition node must define the partitioning aspects of its corresponding structural node.

7.3.6 Rendering for data presentation

The rendering process first constrains the facts to satisfy any table filters associated with the table.

These facts are then arranged in the table according to the constraints associated with its columns, rows and points on the z-axis.

7.3.7 Rendering 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 7.3.6).

Open definition nodes define a part of the rendering 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:

  1. 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-01-16/ - 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-01-16/table.xsd.
  2. 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)

<schema
  xmlns:variable
="http://xbrl.org/2008/variable"

  xmlns
="http://www.w3.org/2001/XMLSchema"

  xmlns:link
="http://www.xbrl.org/2003/linkbase"

  xmlns:xl
="http://www.xbrl.org/2003/XLink"
targetNamespace="http://xbrl.org/PWD/2013-01-16/table" elementFormDefault="qualified">
<annotation>
<appinfo>
<link:arcroleType id="table-breakdown" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/table-breakdown">
<link:definition>
breakdown used on the axes of a table
</link:definition>
<link:usedOn>
table:tableBreakdownArc
</link:usedOn>
</link:arcroleType>
<link:arcroleType id="table-filter" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/table-filter">
<link:definition>
filter applied to table
</link:definition>
<link:usedOn>
table:tableFilterArc
</link:usedOn>
</link:arcroleType>
<link:arcroleType id="definition-node-message" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-message">
<link:definition>
definition node message for header
</link:definition>
<link:usedOn>
gen:arc
</link:usedOn>
</link:arcroleType>
<link:arcroleType id="definition-node-selection-message" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-selection-message">
<link:definition>
human readable rendering transform of a definition-node-selection (for a choice yielded from a selectionNode select expression)
</link:definition>
<link:usedOn>
gen:arc
</link:usedOn>
</link:arcroleType>
</appinfo>
</annotation>
<import namespace="http://www.xbrl.org/2003/XLink" schemaLocation="http://www.xbrl.org/2003/xl-2003-12-31.xsd"/>
<import namespace="http://xbrl.org/2008/variable" schemaLocation="http://www.xbrl.org/2008/variable.xsd"/>
<import namespace="http://xbrl.org/2008/formula" schemaLocation="http://www.xbrl.org/2008/formula.xsd"/>
<import namespace="http://xbrl.org/2008/generic" schemaLocation="http://www.xbrl.org/2008/generic-link.xsd"/>
<!-- these schemas have been merged to this file per WG decision 2012-06-27 <include schemaLocation="rule-axis.xsd" /> <include schemaLocation="composition-axis.xsd" /> <include schemaLocation="relationship-axis.xsd" /> <include schemaLocation="filter-axis.xsd" /> <include schemaLocation="selection-axis.xsd" /> <include schemaLocation="tuple-axis.xsd" /> -->
<!-- original contents of table.xsd -->
<complexType name="table.type">
<complexContent mixed="true">
<extension base="xl:resourceType">
<attribute name="aspectModel" type="token" use="required"/>
<attribute name="parentChildOrder" type="table:parentChildOrder.type" default="parent-first" use="optional"/>
<anyAttribute namespace="http://www.w3.org/XML/1998/namespace" processContents="lax"/>
</extension>
</complexContent>
</complexType>
<simpleType name="cancelableScaleType">
<annotation>
<documentation>
This type is used to specify the value of the scale attribute usable on decimal numeric items. It consists of the union of integer and "" (used to cancel an inherited scale).
</documentation>
</annotation>
<union memberTypes="integer">
<simpleType>
<restriction base="string">
<length value="0"/>
</restriction>
</simpleType>
</union>
</simpleType>
<simpleType name="cancelableNegateType">
<annotation>
<documentation>
This type is used to specify the value of the negate attribute usable on decimal numeric items. It consists of the union of boolean and "" (used to cancel an inherited negate value).
</documentation>
</annotation>
<union memberTypes="boolean">
<simpleType>
<restriction base="string">
<length value="0"/>
</restriction>
</simpleType>
</union>
</simpleType>
<simpleType name="cancelableFormatType">
<annotation>
<documentation>
This type is used to specify the QName value of a transform. It consists of the union of QName and "" (used to cancel an inherited format).
</documentation>
</annotation>
<union memberTypes="QName">
<simpleType>
<restriction base="string">
<length value="0"/>
</restriction>
</simpleType>
</union>
</simpleType>
<simpleType name="cancelableExpressionType">
<annotation>
<documentation>
This type is used to specify the value expression. It consists of the union of variable:expression and "" (used to cancel an inherited expression).
</documentation>
</annotation>
<union memberTypes="variable:expression">
<simpleType>
<restriction base="string">
<length value="0"/>
</restriction>
</simpleType>
</union>
</simpleType>
<attributeGroup name="ordinate.attrs">
<annotation>
<documentation>
Attributes for ordinates (axes that act as ordinates).
</documentation>
</annotation>
<!-- these features have been moved to CSS <attribute name="format" type="table:cancelableFormatType" use="optional" /> <attribute name="scale" type="table:cancelableScaleType" use="optional" /> <attribute name="negate" type="table:cancelableNegateType" use="optional" /> -->
<attribute name="value" type="table:cancelableExpressionType" use="optional"/>
<!-- id and class allow referencing of CSS definitions -->
<attribute name="class" type="NMTOKENS" use="optional"/>
<anyAttribute namespace="http://www.w3.org/XML/1998/namespace" processContents="lax"/>
</attributeGroup>
<attributeGroup name="relationship.attrs">
<annotation>
<documentation>
Attributes for relationships that construct table definitions.
</documentation>
</annotation>
<!-- id and class allow referencing of CSS definitions -->
<attribute name="class" type="NMTOKENS" use="optional"/>
</attributeGroup>
<complexType name="definitionNode.type">
<complexContent mixed="true">
<extension base="xl:resourceType">
<attributeGroup ref="table:ordinate.attrs"/>
</extension>
</complexContent>
</complexType>
<simpleType name="parentChildOrder.type">
<restriction base="token">
<enumeration value="parent-first"/>
<enumeration value="children-first"/>
</restriction>
</simpleType>
<complexType name="closedDefinitionNode.type">
<complexContent mixed="true">
<extension base="table:definitionNode.type">
<attribute name="parentChildOrder" type="table:parentChildOrder.type" use="optional"/>
</extension>
</complexContent>
</complexType>
<element id="xml-table" name="table" substitutionGroup="xl:resource" type="table:table.type"/>
<element id="xml-abstract-definition-node" name="definitionNode" abstract="true" substitutionGroup="xl:resource" type="table:definitionNode.type"/>
<element id="xml-abstract-closed-definition-node" name="closedDefinitionNode" abstract="true" substitutionGroup="table:definitionNode" type="table:closedDefinitionNode.type"/>
<simpleType name="axis.type">
<restriction base="token">
<enumeration value="x"/>
<enumeration value="y"/>
<enumeration value="z"/>
</restriction>
</simpleType>
<element id="xml-table-breakdown-arc" name="tableBreakdownArc" substitutionGroup="gen:arc">
<complexType>
<complexContent>
<extension base="gen:genericArcType">
<attributeGroup ref="table:relationship.attrs"/>
<attribute name="axis" type="table:axis.type" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
<element id="xml-table-filter-arc" name="tableFilterArc" substitutionGroup="gen:arc">
<complexType>
<complexContent>
<extension base="gen:genericArcType">
<attribute name="complement" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
<annotation>
<appinfo>
<link:arcroleType id="definition-node-subtree" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-subtree">
<link:definition>
arc between a parent and child definition node.
</link:definition>
<link:usedOn>
table:definitionNodeSubtreeArc
</link:usedOn>
</link:arcroleType>
</appinfo>
</annotation>
<element id="xml-definition-node-subtree-arc" name="definitionNodeSubtreeArc" substitutionGroup="gen:arc">
<complexType>
<complexContent>
<extension base="gen:genericArcType">
<attributeGroup ref="table:relationship.attrs"/>
</extension>
</complexContent>
</complexType>
</element>
<!-- original contents of rule-axis.xsd -->
<complexType name="ruleNode.type">
<complexContent mixed="true">
<extension base="table:closedDefinitionNode.type">
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="formula:abstract.aspect"/>
</sequence>
<attribute name="abstract" type="boolean" default="false"/>
</extension>
</complexContent>
</complexType>
<element id="xml-rule-node" name="ruleNode" substitutionGroup="table:closedDefinitionNode" type="table:ruleNode.type"/>
<!-- original contents of composition-axis.xsd -->
<element id="xml-composition-node" name="compositionNode" substitutionGroup="table:closedDefinitionNode" type="table:closedDefinitionNode.type"/>
<!-- original contents of relationship-axis.xsd -->
<complexType name="relationshipNode.type">
<complexContent mixed="true">
<extension base="table:closedDefinitionNode.type">
<attribute name="name" type="variable:QName" use="optional"/>
<attribute name="conceptname" type="variable:QName" use="optional"/>
</extension>
</complexContent>
</complexType>
<simpleType name="formulaAxis.type">
<restriction base="token">
<enumeration value="descendant"/>
<enumeration value="descendant-or-self"/>
<enumeration value="child"/>
<enumeration value="child-or-self"/>
<enumeration value="ancestor"/>
<enumeration value="ancestor-or-self"/>
<enumeration value="parent"/>
<enumeration value="parent-or-self"/>
<enumeration value="sibling"/>
<enumeration value="sibling-or-self"/>
<enumeration value="sibling-or-descendant"/>
<enumeration value="sibling-or-descendant-or-self"/>
</restriction>
</simpleType>
<complexType name="conceptRelationshipNode.type">
<complexContent mixed="true">
<extension base="table:relationshipNode.type">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="relationshipSource" type="QName" minOccurs="0" maxOccurs="unbounded"/>
<element name="relationshipSourceExpression" type="variable:expression" minOccurs="0" maxOccurs="unbounded"/>
</choice>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="linkrole" type="xl:nonEmptyURI"/>
<element name="linkroleExpression" type="variable:expression"/>
</choice>
<choice minOccurs="1" maxOccurs="1">
<element name="arcrole" type="xl:nonEmptyURI"/>
<element name="arcroleExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="formulaAxis" type="table:formulaAxis.type"/>
<element name="formulaAxisExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="generations" type="integer"/>
<element name="generationsExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="linkname" type="QName"/>
<element name="linknameExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="arcname" type="QName"/>
<element name="arcnameExpression" type="variable:expression"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="dimensionRelationshipNode.type">
<complexContent mixed="true">
<extension base="table:relationshipNode.type">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="relationshipSource" type="QName" minOccurs="0" maxOccurs="unbounded"/>
<element name="relationshipSourceExpression" type="variable:expression" minOccurs="0" maxOccurs="unbounded"/>
</choice>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="linkrole" type="xl:nonEmptyURI"/>
<element name="linkroleExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="dimension" type="QName"/>
<element name="dimensionExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="formulaAxis" type="table:formulaAxis.type"/>
<element name="formulaAxisExpression" type="variable:expression"/>
</choice>
<choice minOccurs="0" maxOccurs="1">
<element name="generations" type="integer"/>
<element name="generationsExpression" type="variable:expression"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element id="xml-concept-relationship-node" name="conceptRelationshipNode" substitutionGroup="table:closedDefinitionNode" type="table:conceptRelationshipNode.type"/>
<element id="xml-dimension-relationship-node" name="dimensionRelationshipNode" substitutionGroup="table:closedDefinitionNode" type="table:dimensionRelationshipNode.type"/>
<!-- original contents of selection-axis.xsd -->
<complexType name="selectionNode.type">
<complexContent mixed="true">
<extension base="table:definitionNode.type">
<attribute name="name" type="variable:QName" use="optional"/>
<attribute name="select" type="variable:expression" use="required"/>
<attribute name="coveredAspect" use="optional">
<simpleType>
<union memberTypes="QName">
<simpleType>
<restriction base="token">
<enumeration value="concept"/>
<enumeration value="entity-identifier"/>
<enumeration value="period-start"/>
<enumeration value="period-end"/>
<enumeration value="period-instant"/>
<enumeration value="period-instant-end"/>
<enumeration value="unit"/>
</restriction>
</simpleType>
</union>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
<element id="xml-selection-node" name="selectionNode" substitutionGroup="table:definitionNode" type="table:selectionNode.type"/>
<!-- original contents of filter-axis.xsd -->
<annotation>
<appinfo>
<link:arcroleType id="filter-node-filter" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/filter-node-filter">
<link:definition>
filter applied to filter node
</link:definition>
<link:usedOn>
table:filterNodeFilterArc
</link:usedOn>
</link:arcroleType>
</appinfo>
</annotation>
<complexType name="filterNode.type">
<complexContent mixed="true">
<extension base="table:definitionNode.type"/>
</complexContent>
</complexType>
<element id="xml-filter-node" name="filterNode" substitutionGroup="table:definitionNode" type="table:filterNode.type"/>
<element id="xml-filter-node-filter-arc" name="filterNodeFilterArc" substitutionGroup="gen:arc">
<complexType>
<complexContent>
<extension base="gen:genericArcType">
<attribute name="complement" type="boolean" use="required"/>
<attribute name="cover" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
<!-- original contents of tuple-axis.xsd -->
<complexType name="tupleNode.type">
<complexContent mixed="true">
<extension base="table:ruleNode.type">
<!-- substitution rule axis aspects are expected to specify a concept aspect -->
<!-- tuple axis must specify a name, so that the tuple can be referred to for a location rule and contents -->
<attribute name="name" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<element id="xml-tuple-node" name="tupleNode" substitutionGroup="table:ruleNode" type="table:tupleNode.type"/>
<annotation>
<appinfo>
<link:arcroleType id="tuple-content" cyclesAllowed="undirected" arcroleURI="http://xbrl.org/arcrole/PWD/2013-01-16/tuple-content">
<link:definition>
relationship to ruleNode elements that specify tuple contents (nested items and tuples)
</link:definition>
<link:usedOn>
gen:arc
</link:usedOn>
</link:arcroleType>
</appinfo>
</annotation>
</schema>

A.2 Rendering infoset schema (tablemodel.xsd)

<schema
  xmlns
="http://www.w3.org/2001/XMLSchema"

  xmlns:model
="http://xbrl.org/PWD/2013-01-16/table/model"
targetNamespace="http://xbrl.org/PWD/2013-01-16/table/model" elementFormDefault="qualified">
<import namespace="http://xbrl.org/PWD/2013-01-16/table" schemaLocation="table.xsd"/>
<element id="xml-table-model" name="tableModel">
<annotation>
<documentation>
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>
<complexType>
<sequence>
<element id="xml-rendering-table-set" name="tableSet" type="model:tableSet.type" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<complexType name="tableSet.type">
<sequence>
<element id="xml-rendering-table-set-headers" name="headers" type="model:tableSetHeaders.type" minOccurs="0" maxOccurs="unbounded"/>
<element id="xml-rendering-table" name="table" type="model:table.type" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="tableSetHeaders.type">
<annotation>
<documentation>
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>
<element id="xml-rendering-table-set-header" name="header" type="model:header.type" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="table.type">
<annotation>
<documentation>
This type represents a table. A table has fixed axes as described by the table headers.
</documentation>
</annotation>
<choice minOccurs="1" maxOccurs="unbounded">
<sequence>
<element id="xml-rendering-table-headers" name="headers" type="model:headers.type" minOccurs="1" maxOccurs="unbounded"/>
<element id="xml-rendering-table-cells" name="cells" type="model:cells.type" minOccurs="1" maxOccurs="1"/>
</sequence>
</choice>
<attribute name="label" type="string" use="optional"/>
<anyAttribute namespace="http://www.w3.org/XML/1998/namespace" processContents="lax"/>
</complexType>
<complexType name="headers.type">
<annotation>
<documentation>
This type represents the headers for a single axis (x, y or z) of a table.
</documentation>
</annotation>
<sequence>
<element id="xml-rendering-table-header" name="header" type="model:header.type" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attributeGroup ref="model:commonAttributes.group"/>
</complexType>
<complexType name="header.type">
<annotation>
<documentation>
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>
<element id="xml-rendering-label" name="label" type="model:label.type" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="label.type">
<simpleContent>
<extension base="string">
<attribute name="span" type="integer" use="optional" default="1"/>
<attribute name="rollup" type="boolean" use="optional" default="false"/>
</extension>
</simpleContent>
</complexType>
<complexType name="cells.type">
<choice minOccurs="0" maxOccurs="unbounded">
<element name="cells" type="model:cells.type"/>
<element id="xml-rendering-table-cell" name="cell" type="model:cell.type"/>
</choice>
<attributeGroup ref="model:commonAttributes.group"/>
</complexType>
<complexType name="cell.type">
<simpleContent>
<extension base="string">
<attribute name="abstract" type="boolean" use="optional" default="false"/>
</extension>
</simpleContent>
</complexType>
<attributeGroup name="commonAttributes.group">
<attribute name="axis" type="table:axis.type" use="required"/>
</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)
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 LINKS
XBRL International Inc.. "XBRL Generic Links 1.0"
Mark Goodhand
, Ignacio Hernández-Ros, and Geoff Shuetrim.
(See http://www.xbrl.org/Specification/gnl/REC-2009-06-22/gnl-REC-2009-06-22.html)
GENERIC MESSAGES
XBRL International Inc.. "XBRL Generic Messages 1.0"
Masatomo Goto
, Takahide Muramoto, Hitoshi Okumura, Herm Fischer, Andy Harris, and Victor Morilla.
(See http://www.xbrl.org/Specification/genericMessages/PWD-2009-12-16/genericMessages-PWD-2009-12-16.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 2008-07-02"
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-2008-07-02.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)

DateAuthorDetails
01 October 2011Herm Fischer

Initial draft

09 October 2011Victor Morilla

Added comments on issues that require further disucssion

11 October 2011Hugh Wallis

Identified unresolved issues and commented them for publication and feedback solicitation

28 October 2011Herm Fischer

Working group updates: position of coordinate in axes

03 November 2011Herm 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 2011Herm Fischer

Update class diagram, provide schema definitions.

19 December 2011Herm Fischer

Editorial updates suggested by Roland Hommes in WG e-mail of 2011-12-08.

23 April 2012Herm 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 2012Herm 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 2012Herm 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 2012Herm 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 2012Herm Fischer

Added axis-selection-message arcrole arelationship.

11 July 2012Herm 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 2012Herm 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 2012Herm Fischer

Editorial updates suggested by WG e-mails from Shogo Ohyama : (a) Filter axes wording in paragraph 1 of Section 3.2.6.5.1. (b) Filter axes with XPath expressions dependent on other ordinate values by variable names, in Section 3.2.6.5.4.

26 October 2012Jon Siddle

Re-organise content to fit the new three-model approach.

08 November 2012Jon Siddle

Rename (eg axis -> breakdown) according to WG discussion and editorial changes.

09 November 2012Jon Siddle

Add more details on the structural model.

12 November 2012Jon Siddle

Improvements to wording and formatting. Clarify some definitions.

13 November 2012Jon Siddle

Define top level use cases, reorder model descriptions and fix schema validation issues.

19 November 2012Jon Siddle

Clarify various descriptions (particularly in relation to open and closed tables and ordering). Updated figures. Some rewording and formatting improvements.

21 November 2012Jon Siddle

Clarify restrictions on defined axes and tables in a table linkbase. Use new terms more consistently. Update naming for consistency.

26 November 2012Jon 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 2012Jon 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 2012Jon Siddle

Improve subsection headings.

Clarify and expand on descriptions for shape of the table, table cells, coveredAspect, etc.

06 December 2012Jon 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 2012Jon Siddle

Move definitions of models. Other minor changes to clarify terminology. Reorganise and expand rendering sections.

17 December 2012Jon Siddle

Clarification of xfi function usage. Move sections to be consistent with similar specifications, make example non-normative.

20 December 2012Jon 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 2012Jon Siddle

Rendering model and rendering process updates.

Improve description of ordering and Cartesian product of breakdown constraint sets.

07 January 2013Jon Siddle

Minor fixes (missing ID, orphaned comment, etc.).

08 January 2013Jon Siddle

Rename @disposition to @axis in the infoset schema for consistency with the table linkbase schema.

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 16 January 2013.

No errata have been incorporated into this document.