42
EDGAR Filer Manual (Volume II)
6-50
March 2009
This section describes the processing and the semantics of presentation linkbases. The contents
of a presentation linkbase order and arrange the line items, and because order is sometimes
significant, that implies management assertions. Following the semantic rules in this section
helps the registrant to communicate those assertions as they were intended.
6.13.1 A presentation linkbase of a standard taxonomy should not be included in the DTS
of an instance.
An exception to this general rule is when the presentation linkbase is required by a schema that
defines elements or types of a standard taxonomy. Note that in such a case some of the arcs may
have priority attribute values that do not permit overriding.
6.13.2 The element of every fact in an instance must participate in an effective presentation
arc in a base set whose xlink:role attribute corresponds to the locations where the
fact appears in the original HTML/ASCII document.
This rule requires that each link:presentationArc be assigned an xlink:role attribute value placing
facts into the appropriate part of the financial statement at the appropriate level of detail.
6.13.3 Organize the effective presentation arcs in a base set using the ordering and
indentation of the facts in the original HTML/ASCII document.
Order a set of line items to appear as they do in the original HTML/ASCII document by using an
element as their heading that will be the source of presentation arcs that have the line items as
their target. If that heading has no facts associated with it, that element will be an element with
an abstract attribute equal to ‘true’. In other words, to achieve effects such as ordering and
nesting, use presentation arcs, and to insert headings, use abstract elements. A total element often
appears at the end of the list under the heading. Normally, each base set in Rule 6.7.12 above
will have a “root” element that is an abstract element, and that abstract element will be used by
the SEC interactive data viewer to display a heading that precedes all the facts in the base set.
6.13.4 All elements of facts corresponding to parentheticals in the original HTML/ASCII
document must be the targets only of effective presentation arcs in one base set and
all having the same source abstract element.
Filers must declare a link:roleType to contain the parentheticals in each statement, as shown in
the example of Rule 6.7.12, and use an abstract element to serve as a heading for every
parenthetical in that statement. Normally, this would be the same abstract element at the root of
the base set representing the corresponding statement. In example 6.6.14, the element
us-gaap:AccountsReceivable appears in the balance sheet statement, so this rule would be
satisfied with a presentation arc from the element us-gaap:BalanceSheetAbstract to the target
us-gaap:AllowanceForDoubtfulAccountsReceivable in a base set separate from the main balance
sheet statement itself.
6.14 Syntax of Calculation Linkbases
This section defines rules governing the syntax restrictions on calculation linkbases. A valid
Interactive Data calculation linkbase is a valid XBRL 2.1 calculation linkbase, but not all valid
XBRL 2.1 calculation linkbases are valid Interactive Data calculation linkbases.
32
March 2009
6-51
EDGAR Filer Manual (Volume II)
6.14.1 Element link:calculationArc requires an order attribute.
6.14.2 Element link:calculationArc requires a weight attribute equal to 1 or -1.
6.14.3 The source and target of an effective calculation arc must have equal values of the
xblri:periodType attribute.
Facts of elements with different values of the xbrli:periodType attribute must have different
values of the contextRef attribute and therefore the calculation arc between them has no
meaning.
6.14.4 The arc role http://www.xbrl.org/2003/role/summation-item is treated as if it were
declared with link:arcroleType cyclesAllowed attribute equal to ‘undirected’.
This rule prevents a fact from participating in a summation that includes itself.
6.14.5 If an instance contains nonempty facts for the source and target of an effective
calculation arc, then the source and target must appear in effective presentation
arcs in the same base set in the DTS of the instance.
When facts participate in a calculation together, they must be shown with presentation arcs in the
same relationship group, although not necessarily adjacent to each other.
For example, the us-gaap:GrossMargin element has a calculation arc to us-gaap:Revenues in a
group with the xlink:role attribute corresponding to the Statement of Income. If an instance has
nonempty facts for gross margin and revenues, then the xlink:role attribute corresponding to the
Statement of Income must contain one or more presentation arcs to show gross margin and
revenues.
6.15 Semantics of Calculation Linkbases
This section describes the processing and the semantics of calculation linkbases. The content of a
calculation linkbase contains management assertions, and following the semantic rules in this
section helps the filer to communicate those assertions as they were intended.
6.15.1 A calculation linkbase of a standard taxonomy should not be included in the DTS of
an instance.
An exception to this general rule is when the linkbase is required by a schema that defines
elements or types of a standard taxonomy. Note that in such a case some of the arcs may have
priority attribute values that do not permit overriding.
50
EDGAR Filer Manual (Volume II)
6-52
March 2009
6.15.2 If the original HTML/ASCII document shows two or more line items along with
their net or total during or at the end of the Required Context period, and the
instance contains corresponding numeric facts, then the DTS of the instance must
have an effective calculation arc from the total element to each of the contributing
line items.
A calculation arc is a link:calculationArc with an xlink:arcrole attribute equal to
‘http://www.xbrl.org/2003/role/summation-item’. The Required Context is defined in Rule
6.5.19 above.
Examples:
•
A company’s Cash flow from investments for the most recent quarter is shown as the
sum of two lines: Payments for plant and equipment, plus Payments for marketable
securities. Two calculation arcs are required.
•
An income statement shows the line items “Revenues”, “Cost of Goods Sold” and “Gross
margin” as the net of the two values during the current quarter. Two calculation arcs are
required. In this case, the arc subtracting Cost of Goods Sold will have a weight attribute
of -1.
•
A balance sheet shows assets as the sum of current and non-current assets, as of the date
falling at the end of the period of the Required Context. Two arcs are required.
•
An income statement shows only earnings per share and diluted earnings per share, but
no reconciling per-share amount. Calculation arcs are not required.
•
An income statement shows earnings per share before and after an adjustment for change
in accounting principles, along with the adjusting amount. Two calculation arcs are
required, from the net earnings per share, to its two contributing amounts.
•
A balance sheet shows Net Current Receivables with a parenthetical value for
Allowances. Only two values are shown, so no calculation arc is required. In general,
parentheticals do not, by themselves, require calculation arcs.
•
A footnote for ABC contains a table in which the Revenue of its separately reporting
subsidiaries DEF, GHI and JKL are totaled. But, each of the four facts has a different
contextRef attribute. Therefore, this does not require any calculation arcs.
There is no separate, independent requirement that every company-specific element be included
in calculations. It is, however, one of the consequences of this rule that a company-specific
monetary or other numeric item is often defined in such a way that it must participate in
calculation arcs anyway.
6.15.3 Footnotes that contain alternative line items in the original HTML/ASCII document
that separately sum to the same total amount must result in calculation arcs in
distinct base sets.
Calculation inconsistencies are tested separately in each base set.
For example, a tax liability is shown in a tax footnote as the sum of current and deferred tax
liabilities, and elsewhere in the same footnote as the sum of domestic and foreign tax liabilities.
There are two base sets, each containing two calculation arcs.
38
March 2009
6-53
EDGAR Filer Manual (Volume II)
6.15.4 A fact in an instance whose element is the source of an effective calculation arc in
the instance DTS should not have the same calculation arc target in more than one
base set.
An xsd:element should be the source of only one link:calculationArc for any one target, without
regard for base set.
Note that this rule refers to the calculation arc, not the element; an element can occur in any
number of face financial statements or footnotes. Legitimate exceptions to this rule occur when
an element is shown in different parts of the financial statement as a sum of different, but
overlapping, sets of other elements.
Examples:
•
The balance sheet contains amounts pre-tax income, tax, and post-tax income. There are
two line items and their net; therefore two calculation arcs are required in the base set for
the balance sheet. In the tax footnote there is another occurrence of pre-tax income, tax,
and post-tax income. The tax footnote does not need two calculation arcs, because the
same arcs already exist on the balance sheet.
•
A balance sheet shows Net Current Receivables with a parenthetical value for
Allowances. Only two values are shown, so no calculation arc is required. A footnote
also includes an analysis of (the same) Net Current Receivables including, among other
details, amounts for Gross and Allowances. The footnote has those two line items and
their net and therefore a need for two calculation arcs. Whether any of these facts also
appear elsewhere is relevant only if it would result in duplicated arcs.
6.16 Syntax of Definition Linkbases
This section defines rules governing the syntax restrictions on definition linkbases. A valid
Interactive Data definition linkbase is a valid XBRL 2.1 definition linkbase, but not all valid
XBRL 2.1 definition linkbases are valid Interactive Data definition linkbases.
6.16.1 Element link:definitionArc requires an order attribute.
This ensures an intentional displayed order of definition arcs.
6.16.2 The DTS of an instance must contain at most one effective arc with an xlink:arcrole
attribute equal to ‘http://xbrl.org/int/dim/arcrole/dimension-default’ for each Axis
source element.
In an instance, an xbrdli:explicitMember in which there is an effective arc with the xlink:arcrole
attribute ‘http://xbrl.org/int/dim/arcrole/dimension-default’ from the QName value of the
dimension attribute to its QName content is invalid in the XBRL Dimensions 1.0 specification.
42
EDGAR Filer Manual (Volume II)
6-54
March 2009
6.16.3 The target of an effective arc with an xlink:arcrole attribute equal to
‘http://xbrl.org/int/dim/arcrole/dimension-domain’ or
‘http://xbrl.org/int/arcrole/dimension-default’ must be a Domain or Member.
In this rule both the dimension-domain and the dimension-default arc roles must have a source
that is an Axis (xbrldt:dimensionItem); these two rules work together to ensure that each Axis
has an meaningful set of domain members.
6.16.4 The xlink:arcrole attribute ‘http://xbrl.org/int/dim/arcrole/domain-member’ is
treated as if it were declared with a cyclesAllowed attribute equal to ‘none’.
For example, company ABC defines, in us-gaap:SegmentGeographicalDomain, the regions
abc:MidwestMember and abc:SoutheastMember, but stpr:KY (Kentucky) cannot be in both
regions.
This rule also impacts line items, so that the balance at the start and end a roll forward cannot
appear twice under a single axis. The same rendering effect is achieved by including only the
ending balance in the domain-member arcs, so that the beginning balance will appear simply as
the ending balance of the previous period.
Tables define the rows and columns (the axes) that cells (the facts) may have. The domain-
member arc role defines relationships within each row or column, such as those between a parent
entity and its reportable segments, among sets of classes of equity, and or among geographical
regions. Tables become difficult to consistently populate with facts and ambiguous to display
when elements can appear in more than one Domain (or Member). This rule ensures that any
given element does not appear in more than one place along an Axis, and will not have any
overlapping domain subsets or members. In general, almost every situation that at first appears to
call for an Axis with tangled and overlapping subsets of Member elements actually turns out to
be a case more clearly modeled using two distinct axes.
6.16.5 The DTS of an instance must contain in each base set, for each source element, at
most one effective arc with an xlink:arcrole attribute equal to
‘http://xbrl.org/int/dim/arcrole/all’.
A fact can always appear in more than one Table (hypercube), but this rule prevents a fact from
having contradictory meanings in different Tables.
6.16.6 An effective arc with an xlink:arcrole attribute equal to
‘http://xbrl.org/int/dim/arcrole/notAll’ must have an xbrldt:closed attribute equal to
‘false’.
A closed negative hypercube is better modeled with an open positive hypercube.
6.16.7 The target of an effective arc with an xlink:arcrole attribute equal to
‘http://xbrl.org/int/dim/arcrole/notAll’ should be the target of an arc with an
xlink:arcrole attribute equal to ‘http://xbrl.org/int/dim/arcrole/all’ in the same base
set.
An Axis cannot appear as an Axis of a negative hypercube (that is, axis excluded from a table)
unless there is a table with that Axis. This rule establishes sufficient, though stronger than
35
March 2009
6-55
EDGAR Filer Manual (Volume II)
necessary, criteria, to avoid such an anomaly. An instance DTS in which the arc role
‘http://xbrl.org/int/dim/arcrole/notAll’ does not appear will not be affected by this rule.
6.16.8 The target of an effective arc with an xlink:arcrole attribute equal to
‘http://xbrl.org/int/dim/arcrole/notAll’ must not be the target of an effective arc
with an xlink:arcrole attribute equal to ‘http://xbrl.org/int/dim/arcrole/all’ in the
same base set.
This rule ensures that a Table (hypercube) is not both positive and negative.
6.17 Semantics of Definition Linkbases
This section describes the semantics of definition linkbases. The content of a definition linkbase
contains management assertions, and following the semantic rules in this section helps the filer
to communicate those assertions as they were intended.
6.17.1 A definition linkbase of a standard taxonomy should not be included in the DTS of
an instance.
An exception to this general rule is when the linkbase is required by a schema of a standard
taxonomy. Note that in such a case some of the arcs may have priority attribute values that do
not permit overriding.
6.18 Syntax of Reference Linkbases
This section defines rules governing the syntax restrictions on reference linkbases. A valid
Interactive Data reference linkbase is a valid XBRL 2.1 reference linkbase, but not all valid
XBRL 2.1 reference linkbases are valid Interactive Data reference linkbases.
6.18.1 An element that has a company specific namespace must not have a reference.
The elements defined in a company extension schema must not have any authoritative
references.
An xsd:element “has a reference” if the DTS of the instance contains an effective reference arc
whose source is that xsd:element. A reference linkbase should only be attached to a submission
when it is a copy of a linkbase published along with a schema for early adopters. In that situation
the schema would have a targetNamespace attribute of some authority other than the registrant
itself.
A company extension also cannot remove or change references in standard taxonomies (this is a
technical consequence of the rule prohibiting URI fragments other than shorthand xpointers).
6.19 Semantics of Reference Linkbases
This section describes the processing and the semantics of reference linkbases.
36
EDGAR Filer Manual (Volume II)
6-56
March 2009
6.19.1 A reference linkbase of a standard taxonomy should not be included in the DTS of
an instance.
An exception to this general rule is when the linkbase is required by a schema that defines
elements or types of a standard taxonomy. Note that in such a case some of the arcs may have
priority attribute values that do not permit overriding.
6.20 EDGAR Module Processing with XBRL Taxonomy Extensions
EDGAR provides limited support for XBRL taxonomy extension documents as part of EDGAR
Module processing. EDGAR Type 1 Modules (partial documents) are not allowed in XBRL
format. Only EDGAR Type 2 Modules (complete documents) can be submitted in XBRL format.
EDGAR currently supports up to 10 EDGAR Module files per CIK. These 10 Modules may be
used to store any combination of XBRL extension taxonomy files (schema and/or linkbase) and
may be managed by the filer using the EDGAR Filing Website. These taxonomy extension files
may be submitted before the official filing. Through the use of EDGAR Type 2 Module
references to these XBRL documents, EDGAR can assemble these large documents into the
filing without delaying the receipt of the entire filing.
As with any other kind of EDGAR Type 2 Module submission filed with EDGAR, filers may
include an XBRL document, or XBRL documents, as attachments to an EDGAR Module
submission, Template #5. A master submission may reference the XBRL EDGAR Module in a
normal Type 2 fashion by using the Attached Documents page of the submission templates.
6.21 Segment Functionality Not Supported for XBRL Documents
At this time, EDGAR does not support EDGAR segment processing of XBRL documents as
discussed in Section 5.3.
XBRL segments can be used as described in the XBRL Specification. However, segments as
described in Section 5.3 of the EDGARLink Filer Manual are not supported. In EDGARLink,
“segment” refers to parts of a filing that can be submitted ahead of time and later assembled in a
submission. It is this functionality that is not supported for XBRL documents. In the XBRL
Specification 2.1, “segment” also refers to an XBRL tag that is used to provide additional
information in cases where the entity identifier is insufficient. This use of segment is supported.
6.22 Supported Versions of XBRL Standard Taxonomies
Refer to the SEC’s public website (http://www.sec.gov/info/edgar/edgartaxonomies.htm) for an
up-to-datelisting of standard taxonomy files that are supported by EDGAR, their locations,
required namespaces, recommended namespace prefixes, and where appropriate, the relevant
EDGAR form types.
Documents you may be interested
Documents you may be interested
