Copyright © 2011, 2012, 2013 XBRL International Inc., All Rights Reserved.
Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to rendering-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This document specifies semantics and syntax constraints for tables. Tables define subsets of the facts and fact related information, defined by a DTS, and specify representation of those facts in a Cartesian coordinate system.
1 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).
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
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
1 Namespaces and namespace prefixes
2 Relationship node behaviour
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
1 Use of a message to select the preferred label for a concept
2 Rule nodes
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
xbrlte:abstractRuleNodeNoChildren
xbrlte:ambiguousNonAbstractRuleNode
xbrlte:aspectValueNotDefinedByOrdinate
xbrlte:axisAspectClash
xbrlte:axisAspectModelMismatch
xbrlte:axisDefinesNoAspects
xbrlte:axisFilterCoversNoAspects
xbrlte:closedDefinitionNodeZeroCardinality
xbrlte:unknownAspectModel
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.
This specification depends upon the XBRL Specification [XBRL 2.1], the XBRL Dimensions Specification [DIMENSIONS] and the XBRL Formula Specification [FORMULA].
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.
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 |
Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].
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.
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.
Three models are defined by this specification:
The structural model describes a collection of one or more tables defined in a single linkbase, in a way that is independent of the way they were defined.
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.
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.
A table set is a set of one or more tables that share a common definition.
A table definition model may resolve to a series of tables in the structural model. The tables in a table set vary according to the values assigned to the parameters associated with the table definition. Parameter variables may be referenced by definition nodes which affect the shape of the resulting table, such as providing the link role to use in a concept relationship node.
A constraint is 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]
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.
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.
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.
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]
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.
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.
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.
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.
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]
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.
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.
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.
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.
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.
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:
<table:tableFilterArc>
element
http://xbrl.org/arcrole/PWD/2013-01-16/table-filter
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]
The axes of a table are defined by breakdown definitions, which are trees of 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:
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".
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.
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.
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:
<table:definitionNodeSubtreeArc>
element
http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-subtree
<table:closedDefinitionNode>
type at the
starting
resource of the arc <table:closedDefinitionNode>
type at the
ending
resource of the arc[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.
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.
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.
[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 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:
http://xbrl.org/arcrole/PWD/2013-01-16/table-breakdown
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.
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:
http://xbrl.org/arcrole/2008/element-label
arcrole
http://xbrl.org/arcrole/2008/element-reference
arcrole
http://xbrl.org/arcrole/PWD/2013-01-16/definition-node-message
arcrole
http://xbrl.org/arcrole/PWD/2013-01-16/axis-selection-message
.
For example, a definition node that selects link roles (such as
schedules and disclosures) may use an arc role
axis-selection-message to specify displaying of the choices using
either the role-definition or a generic message linked to the role
definition, or an axis that selects a reporting period may display
the fiscal period using an XPath
date formula.
[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. ]
A concept-relationship node binds each traversed relationship to
the conceptRel
variable and each target concept to the
conceptQname
variable.
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.
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]
A number of concrete definition nodes are defined by this specification.
This section specifies semantics and syntax constraints for rule nodes.
The figure below provides a model of the rule node.
A rule node is a closed definition node that defines a structural node whose aspect constraints are defined by aspect rules. It may define an additional roll-up node which has no aspect constraints.
For example, a rule node may specify that a given 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.
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.
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.]
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.]
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"> </table:ruleNode><formula:member> </formula:explicitDimension><formula:qname> </formula:member>eg:Europe </formula:qname><table:ruleNode xlink:type="resource" xlink:label="child2">
<formula:explicitDimension dimension="eg:Geography"> </table:ruleNode><formula:member> </formula:explicitDimension><formula:qname> </formula:member>eg:World </formula:qname><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 |
<table:ruleNode xlink:type="resource" xlink:label="parent" parentChildOrder="children-first">
<formula:explicitDimension dimension="eg:Geography"> </table:ruleNode><formula:member> </formula:explicitDimension><formula:qname> </formula:member>eg:World </formula:qname><table:ruleNode xlink:type="resource" xlink:label="child">
<formula:explicitDimension dimension="eg:Geography"> </table:ruleNode><formula:member> </formula:explicitDimension><formula:qname> </formula:member>eg:Europe </formula:qname><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
|
Each rule node resolves to either one or two structural nodes, as shown in Figure 7 and Figure 8, respectively.
A rule node, D
, always contributes a single structural node,
S
, as a child of the structural node to which the
parent of D
resolves.
All children of D
resolve to children of S
.
The constraints attached to the
structural
node S
are those defined by the
aspect
rules attached to rule
node D
.
If D
is an abstract rule node, it resolves
to the single structural node,
S
, as shown in Figure 7.
An abstract rule node MUST have at least one child.
Error code xbrlte:abstractRuleNodeNoChildren MUST be thrown if the processing software encounters an abstract rule node with no children.
If D
is a non-abstract rule node, 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.
The roll-up node contributes no constraints, so the constraints of its ancestors apply.
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. ]
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.
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).
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.
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:
http://xbrl.org/arcrole/PWD/2013-01-16/tuple-content
,
<table:tupleNode>
type at the starting resource of the
arc <table:ruleNode>
type at the ending resource of the
arc with <tuple:location>
rules
referencing a name of a tupleNode element.
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.
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.
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]
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.
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.
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).
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:
<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.
<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-self
MAY be specified as
noted above to request including the relationship source.
<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.
<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
.
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:
<table:arcrole>
or
<table:arcroleExpression>
element, which is
respectively a non-empty URI or an expression
(xl:nonEmptyURI
).
<table:linkname>
or
<table:linknameExpression>
element, which is
respectively QNames or QName expressions
(xs:QName
).
<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 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).
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:
<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.
@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:
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.
[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.
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).
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).
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.
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.
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:
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?]).
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?]
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.
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.]
<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.]
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.
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.
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?)
]
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.]
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.]
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?]
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:
http://xbrl.org/arcrole/PWD/2013-01-16/filter-node-filter
<table:filterNode>
element at the
starting resource of the arc
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 .
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.
XPath expressions in definition nodes may refer to global parameter variables or variables defined by ancestor nodes in the same breakdown or nodes in any preceding breakdown projected onto the same axis.
For example, a definition node for breakdown by presentation linkbase concept, which is further broken down by a definition linkbase filter, referring to typed dimensions present for the concept of this breakdown, may refer to the presentation linkbase concept above the typed dimension filtering breakdown (both explicitly in an expression, and implicitly by the fact set it processes to determine the structure).
XPath expressions may contain variable references to variables defined by other XPath expressions which need to be evaluated first. This creates a chain of evaluation dependencies which must be evaluated in a certain order.
Processors MUST raise an error if variable references form cyclic dependencies.
Processors MUST be able to resolve a valid chain of variable references.
The 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]
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 z axes.
[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.]
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.
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.
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).
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.
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]
The source for a table used for data presentation is the collection of domain objects considered for table filter matching, axes coordinate matching, and presentation as a cell value.
The source for a table used for data entry is an instance that does not have the facts to be entered (or may have facts with earlier values, to be edited).
This specification defines two "infosets", which are serialisations of two of the three models.
The 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.
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.
A table is represented by a
<tablemodel:table>
element.
A <tablemodel:table>
element must have as its children:
<tablemodel:cells>
element describing the
contents of the table cells
<tablemodel:headers>
elements describing the
headers for each axis of the table.
An optional @label
attribute on the
<tablemodel:table>
element is used to label each table.
The headers for an axis are declared by a <tablemodel:headers>
element.
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
.
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.]
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.
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.
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.
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.
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.
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).
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.
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.]
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.
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:
[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. ]
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.
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.
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.
[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.
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.
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.
The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.
NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:
http://www.xbrl.org/PWD/2013-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.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).
This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).
This document could not have been written without the contributions of many people.
Date | Author | Details |
---|---|---|
01 October 2011 | Herm Fischer |
Initial draft |
09 October 2011 | Victor Morilla |
Added comments on issues that require further disucssion |
11 October 2011 | Hugh Wallis |
Identified unresolved issues and commented them for publication and feedback solicitation |
28 October 2011 | Herm Fischer |
Working group updates: position of coordinate in axes |
03 November 2011 | Herm Fischer |
Working group updates: replace predefinedAxis model with subtrees of ruleAxes and compositions of ruleAxes with relationshipAxes. Replace axis-member notion with that of axis subtree composition. |
05 December 2011 | Herm Fischer |
Update class diagram, provide schema definitions. |
19 December 2011 | Herm Fischer |
Editorial updates suggested by Roland Hommes in WG e-mail of 2011-12-08. |
23 April 2012 | Herm Fischer |
Editorial updates suggested by Takahide Muramoto in WG e-mail of 2012-04-11. Includes new error code axisValueClash, clarification to syntax. parentChildOrder has an example where the parents are first at an outer level of nesting and children are first in more detail breakdowns nested within. |
08 May 2012 | Herm Fischer |
Clarified use of coordinate (orders among axes dispositions taken together) and ordinate (ordering along a single axis disposition). Added Message can be used to label headers in table |
28 May 2012 | Herm Fischer |
Added parentChildOrder attribute to table, made attribute optional in schema, added that it is inheritable, and added an error code of there is no value specified or inheritable on a predefinedAxis element. |
30 May 2012 | Herm Fischer |
Added parentChildOrder table default parent-first, per F2F WG agreement. Added explanation of axis headers, per F2F WG agreement. Moved rendering attributes to CSS specification, per F2F WG agreement, added class attributes to relationships. |
10 July 2012 | Herm Fischer |
Added axis-selection-message arcrole arelationship. |
11 July 2012 | Herm Fischer |
Per WG decision 2012-07-04, merged separate specs into this spec: rule axis, composition axis, relationship axis, tuple axis, selection axis, and filter axis. |
21 July 2012 | Herm Fischer |
Editorial updates suggested by Roland Hommes :
(a) removed error code error-missing-parent-child-order-attribute as
WG agreed to a parentChildOrder inherited from of table element
which has a default;
(b) removed references to standard labels, as they can only apply in
message constructs (due to need to handle role selection when
appropriate to relationship axes);
(c) clarified that language selection for axis headers applies to
label and messages;
(d) clarified ordering of a single ordinate's multiple axis headers
(using |
01 August 2012 | Herm Fischer |
Editorial updates suggested by WG e-mails from Shogo Ohyama : (a) Filter axes wording in paragraph 1 of Section 3.2.6.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 2012 | Jon Siddle |
Re-organise content to fit the new three-model approach. |
08 November 2012 | Jon Siddle |
Rename (eg axis -> breakdown) according to WG discussion and editorial changes. |
09 November 2012 | Jon Siddle |
Add more details on the structural model. |
12 November 2012 | Jon Siddle |
Improvements to wording and formatting. Clarify some definitions. |
13 November 2012 | Jon Siddle |
Define top level use cases, reorder model descriptions and fix schema validation issues. |
19 November 2012 | Jon Siddle |
Clarify various descriptions (particularly in relation to open and closed tables and ordering). Updated figures. Some rewording and formatting improvements. |
21 November 2012 | Jon Siddle |
Clarify restrictions on defined axes and tables in a table linkbase. Use new terms more consistently. Update naming for consistency. |
26 November 2012 | Jon Siddle |
Shuffling of content and rewording, especially in the definition model section. Remove remaining uses of "ordinate". Added missing description. Some formatting improvements. |
28 November 2012 | Jon Siddle |
Expand and clarify a number of descriptions. Some grammar, broken reference and schema validity fixes. Define missing terms. Describe participating aspects and change uses of "covering" to "participating" where appropriate. |
29 November 2012 | Jon Siddle |
Improve subsection headings. Clarify and expand on descriptions for shape of the table, table cells, coveredAspect, etc. |
06 December 2012 | Jon Siddle |
Further wording and formatting improvements. Update rendering model, incorporating some of the suggestions made in the comments. Add a preliminary definition for cells. |
11 December 2012 | Jon Siddle |
Move definitions of models. Other minor changes to clarify terminology. Reorganise and expand rendering sections. |
17 December 2012 | Jon Siddle |
Clarification of xfi function usage. Move sections to be consistent with similar specifications, make example non-normative. |
20 December 2012 | Jon Siddle |
Define abstract / non-abstract nodes and remove explicit roll-up nodes in the definition model, in accordance with WG resolution. Rewrite closed definition node description since previous assertions no longer hold. Describe elimination, and tidy up some no longer relevant descriptions and an error code. Improvements to abstract / non-abstract description. Minor fixes (prefixes, example name, broken reference). |
21 December 2012 | Jon Siddle |
Rendering model and rendering process updates. Improve description of ordering and Cartesian product of breakdown constraint sets. |
07 January 2013 | Jon Siddle |
Minor fixes (missing ID, orphaned comment, etc.). |
08 January 2013 | Jon Siddle |
Rename @disposition to @axis in the infoset schema for consistency with the table linkbase schema. |
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.