Copyright ©2008 XBRL International Inc., All Rights Reserved.
Circulation of this Candidate Recommendation is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to formula-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This specification is a modular extension to the XBRL Specification [XBRL 2.1] that builds upon the XBRL Variables Specification [VARIABLES]. It defines a syntax for formulae that can be processed to produce XBRL facts from information obtained from XBRL reports and their supporting metadata.
1 Introduction
1.1 Background
1.2 Relationship to other work
1.3 Language independence
1.4 Terminology
1.5 Document conventions (non-normative)
1.6 Namespaces and namespace prefixes
1.7 XPath usage
2 Syntax
2.1 Formulae
2.1.1 Value rules
2.1.1.1 Accuracy rules
2.1.2 Aspect rules
2.1.2.1 Required aspect values and sources
2.1.2.2 Default aspect rules
2.1.2.3 Concept rules
2.1.2.4 Entity identifier rules
2.1.2.5 Period rules
2.1.2.6 Dimension rules
2.1.2.6.1 Explicit dimension rules
2.1.2.6.2 Typed dimension rules
2.1.2.7 Open context component rules
2.1.2.7.1 Empty OCC rules
2.1.2.7.2 Fragment OCC rules
2.1.2.7.3 XPath OCC rules
2.1.2.8 Unit rules
2.1.2.8.1 Unit multiplication rules
2.1.2.8.2 Unit division rules
3 The processing model for formulae
A Normative schema
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
1 Formula as documentation of a stock-flow relationship
2 Formula to produce current ratio facts
3 Formulae producing nonsense output
4 Value expressions
5 Accuracy rules
6 Nearest sources
7 Dynamic concept rules
8 Entity identifier rules
9 Period rules
10 Explicit dimension rules
11 Typed dimension rules
12 Fragment OCC rules
13 Unit rules
OCC rule
OCC rule set
XPath OCC rule
accuracy rule
address an aspect
aspect rule
concept rule
default fact variable
default fact variable
dimension rule
empty OCC rule
entity identifier rule
explicit dimension rule
formula
formula expression
formula fact variable
formula input
formula source
formula variable
fragment OCC rule
implied SAV
nearest source
original OCC value
output OCC
output aspect
output concept
output context
output fact
output unit
output value
period rule
required aspect value (RAV)
scenario OCC rule
scenario OCC rule set
segment OCC rule
segment OCC rule set
source
source aspect value (SAV)
subsequent OCC
typed dimension rule
uncovered QName
unit division rule
unit multiplication rule
unit rule
xbrlfe:badSubsequentOCCValue
xbrlfe:badUsageOfExplicitDimensionRule
xbrlfe:badUsageOfTypedDimensionRule
xbrlfe:bindEmptySourceVariable
xbrlfe:conflictingAspectRules
xbrlfe:defaultAspectValueConflicts
xbrlfe:illegalUseOfUncoveredQName
xbrlfe:incompleteConceptRule
xbrlfe:incompleteEntityIdentifierRule
xbrlfe:incompletePeriodRule
xbrlfe:missingConceptRule
xbrlfe:missingEntityIdentifierRule
xbrlfe:missingPeriodRule
xbrlfe:missingSAVForExplicitDimensionRule
xbrlfe:missingSAVForTypedDimensionRule
xbrlfe:missingSAVForUnitRule
xbrlfe:missingUnitRule
xbrlfe:nonSingletonOutputValue
xbrlfe:nonexistentSourceVariable
xbrlfe:sequenceSAVConflicts
xbrlfe:undefinedSAV
xbrlfe:unrecognisedAspectRule
xbrlfe:wrongXpathResultForTypedDimensionRule
xbrlfe:wrongXpathResultForXpathRule
This specification defines a syntax that can be used to document the rules for deriving new XBRL facts from information obtained from XBRL instances.
The transformation rules expressed in a formula serve two purposes. First, they constitute additional documentation about the facts being reported in XBRL instances.
A formula that sets out the rules for transforming a starting balance and subsequent flows into an ending balance provides documentation of the relationship between the concept used to report balances and the concepts used to report the flows that affect those balances. It also documents the nature of the constraints on the periods for facts that have the stock-flow relationship defined by the formula.
Second, formulae can be processed to produce XBRL facts. When evaluated successfully against an XBRL instance, formulae produce new XBRL facts.
A simple formula may state that the current ratio is equal to current assets divided by current liabilities. Given an instance that reports values for current assets and current liabilities, the formula can be processed to obtain a value for the current ratio, along with the context, the units and the reporting precision for the computed current ratio.
Note that, for this formula to execute, the facts reporting current assets and liabilities would need to have matching contexts and units.
The general processing model for a formula is to apply the formula against a single XBRL instance, referred to as the target XBRL instance.
In the event that a formula needs to be evaluated against a set of facts that span several XBRL instances, those instances will need to be merged prior to processing. Such merge operations can, in some circumstances, lead to problems in the discoverable taxonomy set supporting the combined XBRL instance. The resolution of these problems is outside the scope of this specification.
It is entirely possible for formula evaluation to produce results that violate XML Schema content models for XBRL facts or their contexts.
A formula could produce a non-numeric value for a fact that is to report values for a numeric concept. This would lead to an XML Schema validation problem in the output XBRL instance.
A formula could also produce entity identification scheme values that are not valid Uniform Resource Identifiers.
In many cases, these problems will only be detectable through XBRL validation of the XBRL instances produced by formulae.
Formulae have been designed to be general enough to support a wide range of specific usage patterns such as validation of XBRL instances against a set of business rules. These more specific usage patterns will be defined in specifications that build upon this specification.
This specification is built on the fact selection capabilities of the XBRL Variables Specification [VARIABLES]. It extends the range of information that can be captured in discoverable taxonomy sets and provides a syntax for expressing complex formulaic relationships in terms that relate to XBRL data structures.
This specification depends upon the XBRL Specification [XBRL 2.1], the XBRL Variables Specification [VARIABLES]. In the event of any conflicts between this specification and the specifications upon which it depends, this specification does not prevail.
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
This specification is consistent with the definitions of any of the terms defined in specifications that it depends on.
Documentation conventions follow those set out in the XBRL Variables Specification [VARIABLES].
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 is consistent
with
Table
1.
The prefix column in Table 1 is non normative. The namespace URI column is normative.
Prefix | Namespace URI |
---|---|
formula
|
http://xbrl.org/2008/formula
|
xbrlfe
|
http://xbrl.org/2008/formula/error
|
eg
|
http://example.com/
|
fn
|
http://www.w3.org/2005/xpath-functions
|
link
|
http://www.xbrl.org/2003/linkbase
|
xbrli
|
http://www.xbrl.org/2003/instance
|
xfi
|
http://www.xbrl.org/2008/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
|
iso4217
|
http://www.xbrl.org/2003/iso4217
|
This specification only provides a textual declaration of syntax constraints when those constraints are not expressed by the normative schema supplied with this specification.
Explanations of elements and attributes are only supplied when explanations are not already provided in other specifications.
Unless explicitly stated otherwise, a reference to a specific element MUST be read as a reference to that element or to any element in its substitution group.
A formula is declared by a
<formula:formula>
element.
The syntax for the
<formula:formula>
element is defined by the normative schema supplied with this specification.
A formula expresses a set of rules for constructing an output XBRL fact by transforming the values that the variables in the formula's variable set have evaluated to. The values of the variables are obtained from an XBRL instance and its supporting DTS or from the application processing the formula.
A formula variable is a variable in the variable set of a formula.
A formula fact variable is a fact variable in the variable set of a formula.
An output fact is a fact that is produced by evaluation of a formula.
The rules included in a formula cover construction of:
Formulae do not provide any guidance on the values to use for
the
@id
attribute on the contexts or units that are
referenced by output facts. Such values are application
dependent.
An output value is the value of an output fact.
An output aspect is the value of an aspect for an output fact.
An output concept is the concept that an output fact reports a value for.
An output context is the context of an output fact.
An output unit is the unit of measurement for an output fact.
A formula expression is the content of the
@value
attribute on a
<formula:formula>
element.
A formula expression is an XPath expression. When evaluated successfully, it produces the value of a single XBRL item.
If evaluation of the value expression results in an empty sequence, then the
output fact MUST be reported as a nil fact, using the
XML Schema Instance
attribute
@xsi:nil
with a value of true
.
Error code xbrlfe:nonSingletonOutputValue MUST be thrown if a value expression evaluates to produce a sequence that contains more than one item.
Formula expressions are evaluated using the
<xbrli:xbrl>
element of the
target XBRL instance
as the context item.
Value expression | Output fact value | Comments |
---|---|---|
1.2
|
1.2
|
|
'Hello world'
|
Hello world
|
The single quotes around the text in the value expression are required to identify it as an XPath string. |
$eg:variableA gt $eg:variableB
|
true
|
This result presumes that the value of variable eg:variableA is greater than
the value of variable eg:variableB .
|
()
|
@xsi:nil equals true
|
The output fact is nil because the value expression always produces an empty sequence. |
$eg:factVariableA intersect $eg:factVariableB
|
@xsi:nil equals true
|
The output fact is nil assuming that
variable eg:factVariableA contains no facts that
are also in variable eg:factVariableB .
|
$eg:factVariableA intersect $eg:factVariableB
|
13
|
The output fact is 13 assuming that
variable eg:factVariableA contains one fact that
is also in variable eg:factVariableB and that fact
has a value of 13 .
|
$eg:factVariableA intersect $eg:factVariableB
|
An error is thrown. |
An error is thrown if
variable eg:factVariableA contains more than one fact that
is also in variable eg:factVariableB .
|
$eg:factVariableA |
12.3
|
This result presumes that variable
eg:factVariableA has evaluated to a single fact with
a value of 12.3 .
|
fn:sum($eg:variableA) |
10000
|
This result presumes that the sequence of facts that
variable eg:variableA has evaluated to
have values that sum to 10000 .
|
In XBRL non-fraction numeric facts are reported with information about their
accuracy in the form of a
@precision
or
@decimals
attribute.
Formulae MAY contain rules governing the determination
of the accuracy to be asserted for an output fact.
An accuracy rule is a rule for determining the accuracy (expressed as a precision or number of decimal places) to be asserted for numeric output facts.
All formulae have a default accuracy rule. A formula MAY also
have an accuracy rule specified by either a
<formula:precision>
child
element or a
<formula:decimals>
child element on the formula.
If a formula contains a
<formula:decimals>
child element, then
non-fraction numeric output items MUST report their accuracy with a
@decimals
attribute. The value of this attribute MUST be
obtained by evaluating the XPath expression in the
<formula:decimals>
child
element using the
<xbrli:xbrl>
element of the target XBRL instance as the
context item.
Otherwise, non-fraction numeric output items MUST report their accuracy with a
@precision
attribute. If the formula contains a
<formula:precision>
child element, the
value of the
@@precision
attribute for numeric output items MUST be obtained
by evaluating the XPath expression in the
<formula:precision>
child element
using the
<xbrli:xbrl>
element of the target XBRL instance as the context item.
Otherwise, the value of the
@precision
attribute MUST default to
zero.
Decimals rule XPath expression | Precision rule XPath expression | Output fact value | Output accuracy |
---|---|---|---|
Omitted | Omitted | 1000000 |
|
-6 | Omitted | 1000000 |
|
omitted | 1 | 1000000 |
|
Along with rules for determining output fact values and their precision, formulae specify or imply rules that determine values for all of the output aspects required to interpret output values.
An aspect rule is a rule for determining the value of an output aspect. Rules for determining the output concept, the output context and the output units of measurement (for numeric facts), are all different types of aspect rules.
The XBRL Variables Specification [VARIABLES] supports the definition of new aspects. In line with the ability to extend the variable specification by defining new aspect models, the formula specification supports the definition of new aspect rules to support new aspect definitions.
An aspect rule addresses an aspect if can be used to determine a value for that aspect for the output facts produced by formulae that include instances of the aspect rule. Every specification of an aspect rule MUST identify the aspect or aspects that the aspect rule addresses and the conditions, if any, under which the aspect rule does address those aspects.
Some aspect rules combine to fully specify the output value for an aspect. The specification of such aspect rules MUST explain how the rules are to be combined with others to obtain a single output aspect value.
This specification defines aspect rules that address the aspects defined in the XBRL Variables Specification [VARIABLES].
The output aspects that a formula can generate MUST be consistent with the formula's aspect model.
Error code xbrlfe:unrecognisedAspectRule MUST be thrown if a formula includes an aspect rule for an aspect that is not defined in the formula's aspect model.
Formulae MUST include all of the aspect rules necessary to produce an output fact. All aspect models are required to include specific aspects as defined in the XBRL Variables Specification.
Error code xbrlfe:missingConceptRule MUST be thrown if a formula omits an aspect rule for the concept aspect.
Error code xbrlfe:missingEntityIdentifierRule MUST be thrown if a formula omits an aspect rule for the entity identifier aspect.
Error code xbrlfe:missingPeriodRule MUST be thrown if a formula omits an aspect rule for the period aspect.
Error code xbrlfe:missingUnitRule MUST be thrown if a formula produces a numeric item but omits an aspect rule for the unit aspect.
Error code xbrlfe:conflictingAspectRules MUST be thrown if a formula has aspect rules that impose conflicting requirements on the values of output aspects.
Conflicting aspect rules are possible in an XML Schema valid formula
resource because a formula resource permits any number and combination
aspect rules so long as they are all in the substitution group
for the
<formula:abstract.aspect>
element.
As an example of conflicting aspect rules, an XML Schema valid formula can include more than one concept rule. Even if all of the concept rules in the formula always specify the same value for the output concept, they still constitute conflicting aspect rules.
All aspect rules specify an aspect value that the output aspect is required to match.
The required aspect value (RAV) is the value of an aspect, that MUST be matched by output values for the same aspect.
Aspect rules can specify their RAV directly or in terms of one or more aspect values in the target XBRL instance.
A source aspect value (SAV) is an aspect value in the target XBRL instance.
If an aspect rule specifies its RAV in terms of one or more SAVs, then it MUST provide a means of identifying which SAVs to use.
The
@source
attribute on formulae and their descendent elements
supports a SAV identification system for aspect rules.
A source is a
@source
attribute on a formula or
any one of its descendent elements.
Aspect rules can depend on SAVs that are identified by a source.
A formula source is a source on a
<formula:formula>
element.
The QName value, formula:uncovered
, is referred to as
the uncovered QName.
Sources contain a QName that MUST be either the uncovered QName or the QName of one of the formula's fact variables.
An implied SAV is the SAV implied for an aspect by a source that equals the uncovered QName.
Given an aspect rule, the implied SAV for a source that equals the uncovered QName can be determined as follows:
Error code xbrlfe:undefinedSAV MUST be thrown if a source does not imply a SAV for an aspect rule that depends on it.
Matching of uncovered aspects by implicit filtering, as defined in the Implicit filtering specification [IMPLICIT FILTERS], will ensure that the SAV implied is independent of the actual fact chosen.
Error code xbrlfe:illegalUseOfUncoveredQName MUST be thrown if a source contains the uncovered QName but its formula does not use implicit filtering.
This error prevents the uncovered QName from being used in formulae where there is no guarantee of matching aspect values across the variables that could be used to determine the implied SAV.
Given an aspect rule, the SAV implied by a source that equals the QName of one of the formula's fact variables can be determined as follows:
Error code xbrlfe:sequenceSAVConflicts MUST be thrown if a source contains the QName of a fact variable that binds as a sequence unless the formula uses implicit filtering and the aspect rule addresses an aspect that is not covered by a filter for the fact variable.
Error code xbrlfe:nonexistentSourceVariable MUST be thrown if a source in a formula contains a QName that is not the uncovered QName or the QName of any one of the formula's fact variables.
Error code xbrlfe:bindEmptySourceVariable MUST be thrown if a formula's source contains the QName of a fact variable that can bind to an empty sequence.
Note that the source in a formula, referred to in the above errors,
can be defined by the
@source
attribute on the
<formula:formula>
element itself or on any of
its descendant elements.
A formula can contain more than one source. However, an aspect rule or a component thereof, can only refer to its nearest source.
The nearest source to an aspect rule, or a component thereof, is the source on the element expressing the rule or component, or, if that doesn't exist, the source on its closest ancestor element.
aspect rule | nearest source |
---|---|
entity identifier |
eg:variableA
|
period |
eg:variableB
|
unit |
eg:variableC
|
unit multiplication |
eg:variableD
|
All of the aspect rules in a formula are expressed by
elements that are children of
<formula:aspects>
child elements of the formula.
A single source can be used by all or some of the aspect
rules in a formula. To support this use of the one source
by multiple aspect rules, formulae allow a source to be specified
by a
@source
attribute on the formula itself.
Formulae also allow sources to be specified on the
<aspects>
child elements of formulae. Aspect rules, and parts thereof can
also contain their own sources.
Formulae have default aspect rules. Like other aspect rules, a default aspect rule specifies a value for an aspect. However, a default aspect rule applies only if a formula does not have an alternative aspect rule that addresses the same aspect.
All formulae have a default
location aspect
rule, which requires output facts to be child elements of the
target XBRL instance's
<xbrli:xbrl>
element.
Formulae only have default rules for other aspects if they have a formula source.
If a formula has a formula source, then it defines default aspect rules for aspects, other than the location aspect, in terms of that formula source.
If the formula source equals the uncovered QName then the formula has a default aspect rule for each aspect that is uncovered for at least one of the formula's fact variables. The default aspect rule for each of those aspects requires that the output value for that aspect to match the SAV for that aspect, as defined by the formula source.
Error code xbrlfe:defaultAspectValueConflicts MUST be thrown if a formula source equals the QName of a formula fact variable that binds as a sequence.
If the formula source equals the QName of one of the formula's fact variables then that fact variable is known as the default fact variable.
The single fact in the sequence that the default fact variable has evaluated to is known as the default fact.
The formula has a default aspect rule for each aspect of the default fact. Each of these default aspect rules requires that the output aspect of the addressed aspect matches the value of that aspect for the default fact.
Default unit aspect rules only apply if the output fact is a numeric item.
A concept rule is an aspect rule that addresses the
concept aspect and
that is expressed by a
<formula:concept>
element.
Concept rules indicate the RAV in one of three ways.
If a concept rule has no child elements then its RAV is its SAV.
If a concept rule has a child
<formula:qname>
element then its RAV is
the concept with the QName contained by the
<formula:qname>
element.
If a concept rule has a child
<formula:qnameExpression>
element then its RAV is
the concept with the QName obtained by evaluating the XPath expression the
<formula:qnameExpression>
element using the target XBRL instance's
<xbrli:xbrl>
element as the context item.
Error code xbrlfe:incompleteConceptRule MUST be thrown if a concept rule does not have a nearest source and does not have a child element.
<formula:qnameExpression>
|
Output concept |
---|---|
fn:node-name($eg:factVariable) |
The output concept would be required to be the same concept as that
of the facts that variable eg:factVariable has evaluated to.
|
An entity identifier rule is an aspect rule that addresses the
entity
identifier aspect and that is expressed by the
<formula:entityIdentifier>
element.
An entity identifier rule specifies its RAV in terms of variations on its SAV.
If the entity identifier rule contains a
@scheme
attribute then the RAV MUST have an entity
identifier scheme that is s-equal to that obtained by
evaluating the XPath expression contained by the
@scheme
attribute.
Otherwise, the RAV MUST have an entity identifier scheme
that is s-equal to the entity identifier scheme in the SAV.
If the entity identifier rule contains a
@value
attribute then the RAV MUST have an entity
identifier value that is s-equal to that obtained by
evaluating the XPath expression contained by the
@value
attribute.
Otherwise, the RAV MUST have an entity identifier value
that is s-equal to the entity identifier value in the SAV.
Error code xbrlfe:incompleteEntityIdentifierRule
MUST be thrown if an entity identifier rule
does not have a nearest source and does not have either a
@scheme
or a
@value
attribute.
SAV entity identifier | Entity identifier rule | Output entity identifier | ||||
---|---|---|---|---|---|---|
scheme | value |
@scheme
|
@value
|
scheme | value | Comments |
http://my.com
|
1324-ABCD
|
http://my.com
|
1324-ABCD
|
The output entity identifier is determined by the SAV. | ||
http://my.com
|
1324-ABCD
|
'http://your.com'
|
http://your.com
|
1324-ABCD
|
The output entity identifier scheme is determined by the entity identifier rule. | |
http://my.com
|
1324-ABCD
|
'http://your.com'
|
'5678-EFGH'
|
http://your.com
|
5678-EFGH
|
The output entity identifier value is also determined by the entity identifier rule. |
A period rule is an aspect rule that addresses the
period aspect
and that is expressed by the
<formula:period>
element.
A period rule provides specific rules for constructing the period in the output context.
If a period rule has no child elements then its RAV is its SAV.
If the period rule has a
<formula:forever>
child element
then the RAV is a forever period.
If the period rule has a
<formula:instant>
child element
then the RAV has an instant with a value that is equal to that obtained by
evaluating the XPath expression contained by the
@value
attribute
on the
<formula:instant>
element.
If the period rule has a
<formula:duration>
child element
then the RAV has a finite duration with a start value that is equal to that
obtained by evaluating the XPath expression contained by the
@start
attribute on the
<formula:duration>
element and
an end value that is equal to that obtained by
evaluating the XPath expression contained by the
@end
attribute on the
<formula:duration>
element.
The context item for evaluation of all XPath expressions in period rules is the
<xbrli:xbrl>
element in the target XBRL instance.
Error code xbrlfe:incompletePeriodRule MUST be thrown if a period rule does not have a nearest source and does not have a child element.
SAV | Period rule | Output period |
---|---|---|
Instant date is 2006-12-31 and
instant time is omitted.
|
RAV is the SAV |
Output period is an instant with a date of 2006-12-31 and
a time that is omitted or an instant with a date of 2007-01-01
and a time of 00:00:00 .
|
Instant date is 2006-12-31 and
instant time is omitted.
|
Period rule contains a
<formula:forever>
element. |
Output period specifies a period aspect value of forever. |
A dimension rule is an aspect rule that is either an explicit dimension rule or a typed dimension rule.
Explicit dimension rules and typed dimension rules are defined in Section 2.1.2.6.1 and Section 2.1.2.6.2 respectively.
An explicit dimension rule is an aspect rule
for an explicit dimension aspect
that is expressed by the
<formula:explicitDimension>
element.
Explicit dimension rules specify RAVs for explicit dimension aspects.
Explicit dimension rules specify a RAV either explicitly, or by reference to a SAV.
The dimension,
affected by an explicit dimension rule is specified by the QName in the
@dimension
attribute on the dimension rule.
Error code xbrlfe:badUsageOfExplicitDimensionRule
MUST be thrown if the
@dimension
attribute on the dimension rule
contains a QName that does not identify an explicit dimension.
If an explicit dimension rule contains no child elements, then the explicit dimension rule specifies that the output fact MUST include an dimension aspect value for the dimension identified by the explicit dimension rule. It also specifies that the value for that dimension aspect MUST be the SAV for that dimension aspect.
Error code xbrlfe:missingSAVForExplicitDimensionRule
MUST be thrown if an explicit dimension rule
does not have any child elements and does not have a SAV for
the dimension that identified by its
@dimension
attribute.
If an explicit dimension rule contains a
<formula:member>
element, then that
element identifies the QName of the domain member that is to be the RAV.
If the
<formula:member>
element contains a child
<formula:qname>
element,
then the QName of the domain member is the value of the
<formula:qname>
element.
If the
<formula:member>
element contains a child
<formula:qnameExpression>
element
then the QName of the domain member is the QName obtained by evaluating its content as an XPath
expression using the
<xbrli:xbrl>
element of the target XBRL instance as the context item.
If an explicit dimension rule contains a
<formula:member>
element, then
the output fact MUST
include a dimension aspect value for the specified dimension with the
value specified by the
<formula:member>
element.
If an explicit dimension rule contains a
<formula:omit>
element then the dimension identified
by the explicit dimension rule MUST NOT
have a value for the output fact.
Explicit dimension rule | Explanation |
---|---|
<formula:explicitDimension dimension="eg:ProductDim">
<formula:member> </formula:explicitDimension><formula:qname> </formula:member>eg:Cars </formula:qname> |
Add explicit dimension eg:ProductDim
with value eg:Cars .
|
<formula:explicitDimension dimension="eg:ProductDim"/>
|
Add dimension eg:ProductDim with value of that dimension
given by the SAV.
|
<formula:explicitDimension dimension="eg:dCustomer">
<formula:omit/> </formula:explicitDimension> |
Do not report a value for the eg:dCustomer
dimension for the output fact.
|
A typed dimension rule is an aspect rule
for a typed dimension aspect
that is expressed by the
<formula:typedDimension>
element.
Typed dimension rules specify RAVs for typed dimension aspects.
Typed dimension rules specify a RAV either explicitly, or by reference to a SAV.
The dimension,
affected by a typed dimension rule is specified by the QName in the
@dimension
attribute on the dimension rule.
Error code xbrlfe:badUsageOfTypedDimensionRule
MUST be thrown if the
@dimension
attribute on the dimension rule
contains a QName that does not identify a typed dimension.
If a typed dimension rule contains no child elements, then the typed dimension rule specifies that the output fact MUST include an dimension aspect value for the dimension identified by the typed dimension rule. It also specifies that the value for that dimension aspect MUST be the SAV for that dimension aspect.
Error code xbrlfe:missingSAVForTypedDimensionRule
MUST be thrown if a typed dimension rule
does not have any child elements and does not have a SAV for
the dimension that identified by its
@dimension
attribute.
If a typed dimension rule has a child element, it will be one of three different children:
a
<formula:xpath>
element, a
<formula:value>
element or a
<formula:omit>
element.
If an typed dimension rule contains a
<formula:xpath>
element then that element contains an XPath expression that, when evaluated,
MUST yield a sequence containing a single element
node. This element node (and its descendants, if any) are the content
of the root element of the typed dimension value for the output fact.
The context item for evaluation of the XPath expression contained
by the typed dimension rule is the
<xbrli:xbrl>
element of
the target XBRL instance.
Error code xbrlfe:wrongXpathResultForTypedDimensionRule MUST be thrown if the result of evaluating the XPath expression in a typed dimension rule is not a sequence containing a single element node.
If an typed dimension rule contains a
<formula:value>
element then that element has a single child element.
That child element must be s-equal2
to the child element of the typed dimension value for the output fact.
If an typed dimension rule contains a
<formula:omit>
element then the dimension identified
by the typed dimension rule MUST NOT
have a value for the output fact.
Typed dimension rule | Explanation |
---|---|
<formula:typedDimension dimension="eg:statusDim">
<formula:value> </formula:typedDimension><audited/> </formula:value> |
Add typed dimension value for dimension eg:statusDim
with content
.
|
<formula:typedDimension dimension="eg:statusDim"/>
|
Add dimension eg:statusDim with a value
given by the SAV.
|
<formula:typedDimension dimension="eg:statusDim">
<formula:omit/> </formula:typedDimension> |
Do not report a value for the eg:statusDim
dimension for the output fact.
|
An OCC rule, is an aspect rule that addresses an
OCC aspect
and that is in the
substitution group
for the
<formula:abstract.occ.aspect>
element.
An output OCC, is the value of an OCC for the output fact.
A segment OCC rule is an OCC rule
with an
@occ
attribute equal to segment
.
A scenario OCC rule is an OCC rule
with an
@occ
attribute equal to scenario
.
A formula MAY contain multiple segment OCC rules and multiple scenario OCC rules.
The segment OCC rule set for a formula is the set of segment OCC rules that the formula contains. They are evaluated together to determine output OCC for the segment.
The scenario OCC rule set for a formula is the set of scenario OCC rules that the formula contains. They are evaluated together to determine output scenario OCCs.
An OCC rule set is general term for a segment OCC rule set or a scenario OCC rule set.
The OCC rules in a OCC rule set MUST be processed in document order to obtain the output OCC value.
The original OCC value for an OCC rule is the OCC value that is modified by application of that OCC rule.
The subsequent OCC for an OCC rule is the OCC value resulting from application of that OCC rule to its original OCC.
Error code xbrlfe:badSubsequentOCCValue MUST be thrown if a subsequent OCC value contains information that implies a value for any other aspect in the aspect model of the formula than the OCC aspect whose value is being determined by the OCC rule being processed.
Thus, for example, ( xbrlfe:badSubsequentOCCValue ) would be thrown for a formula with a dimensional aspect model if an OCC rule produced a subsequent OCC value that included content that implies a dimension aspect value.
The subsequent OCC value for one OCC rule is the original OCC value for the OCC rule that is processed next.
The RAV specified by an OCC rule set is the subsequent OCC value for the last OCC rule to be processed in that set.
The following sub-sections define the syntax and semantics for specific OCC rules. Extension specifications MAY define additional OCC rules.
An empty OCC rule is an OCC rule that is
expressed by the
<formula:occEmpty>
element.
An empty OCC rule produces a subsequent OCC value that is an empty sequence of aspect values regardless of the original OCC value. It is generally used as the first OCC rule in an OCC rule set.
A fragment OCC rule is an OCC rule that is
expressed by the
<formula:occFragments>
element.
A fragment OCC rule extends an original OCC value by appending its child elements (and their descendants, if any) to obtain a subsequent OCC value.
Original OCC value | Child elements of the fragment OCC rule | Subsequent OCC value |
---|---|---|
<eg:budget/>
|
<eg:budget/>
|
|
<eg:confidential/>
|
<eg:audited/>
|
<eg:confidential/> <eg:audited/>
|
An XPath OCC rule is an OCC rule that is
expressed by the
<formula:occXPath>
element.
An XPath OCC rule contains an XPath expression in its
@select
attribute that, when evaluated,
MUST yield a sequence of element
nodes. These element nodes (and their
descendants, if any) are appended to an
original OCC value to obtain a subsequent OCC value.
The context item for evaluation of the XPath expression contained
by an XPath OCC rule is the
<xbrli:xbrl>
element of
the target XBRL instance.
Error code xbrlfe:wrongXpathResultForXpathRule MUST be thrown if the result of evaluating the XPath expression in an XPath rule is not a sequence of element nodes.
A unit rule is an aspect rule that addresses the
unit aspect
and that is expressed by the
<formula:unit>
element.
Unit rules specify the unit RAV for numeric output facts in terms of zero or more modifications to their SAV. The modifications are expressed by sub-rules of the unit rule.
If a unit rule contains an
@augment
attribute with a
value of true
then the SAV for the unit rule is determined
as usual. If a unit rule contains an
@augment
attribute with a
value of false
then the SAV is not defined.
Error code xbrlfe:missingSAVForUnitRule MUST be thrown if a unit rule does not have any child elements and does not have a SAV.
For formulae that need the output unit to vary in one or more respects from units in the target XBRL instance, unit rules use child elements that express multiplication sub-rules (See Section 2.1.2.8.1) and unit division sub-rules (See Section 2.1.2.8.2).
The RAV for a unit rule is obtained by the following sequence of steps:
If the collection of numerator measures and the collection of denominator measures are both empty, then the RAV MUST be a single numerator measure with the value: xbrli:pure.
Otherwise, the RAV for the unit rule MUST have a measure in its numerator for each measure in the combined collection of numerator measures obtained from the steps given above and a measure in its denominator for each measure in the combined collection of denominator measures, also obtained from the steps given above.
Implicit measures1 | Reference measures2 | Unit rule | Output measures | ||||
---|---|---|---|---|---|---|---|
numerator | denominator | numerator | denominator | augment | measures | numerator | denominator |
eg:kilometers
|
eg:hours
|
true
|
eg:kilometers
|
eg:hours
|
|||
eg:kilometers
|
eg:hours
|
true
|
divide by eg:hours
|
eg:kilometers
|
eg:hours
eg:hours
|
||
iso4217:EUR
|
iso4217:USD
|
true
|
iso4217:USD
|
||||
iso4217:EUR
|
iso4217:USD
|
false
|
multiply by xbrli:shares
|
xbrli:shares
|
|||
iso4217:EUR
|
iso4217:USD
|
true
|
multiply by xbrli:shares and
divide by iso4217:USD
|
xbrli:shares
|
|||
iso4217:EUR
|
iso4217:USD
|
false
|
multiply by xbrli:shares and
divide by iso4217:USD
|
xbrli:shares
|
iso4217:USD
|
1. The implicit measures are the measures in the implicit unit aspect value.2. The reference measures are the measures in the reference unit aspect value.
A unit multiplication rule is expressed by the
<formula:multiplyBy>
child element of a
<formula:unit>
element.
Each unit multiplication rule defines a collection of one or more measures to add to the numerator measures of the containing unit rule's RAV.
Each unit multiplication rule also defines a, possibly empty, collection of measures to add to the denominator measures of the containing unit rule's RAV.
If a unit multiplication rule contains no
@measure
attribute, then its collection of numerator measures
is the collection of measures in the numerator of the
unit SAV for the unit multiplication rule. Also,
its collection of denominator measures is the
collection of measures, if any, in the denominator of
the unit SAV for the unit multiplication rule.
Otherwise, a unit multiplication rule specifies a
singleton collection of numerator measures. The single
measure in that collection contains the QName
resulting from evaluation of the XPath expression
contained by the
@measure
attribute on
the unit multiplication rule. Such unit
multiplication rules specify an empty collection
of denominator measures.
A unit division rule
is expressed by the
<formula:divideBy>
child element of a
<formula:unit>
element.
Each unit division rule defines a collection of one or more measures to add to the denominator measures of the containing unit rule's RAV.
Each unit division rule also defines a, possibly empty, collection of measures to add to the numerator measures of the containing unit rule's RAV.
If a unit division rule contains no
@measure
attribute, then its collection of denominator measures
is the collection of measures in the numerator of the
unit SAV for the unit division rule. Also,
its collection of numerator measures is the
collection of measures, if any, in the denominator of
the unit SAV for the unit division rule.
Otherwise, a unit division rule specifies a
singleton collection of denominator measures. The single
measure in that collection contains the QName
resulting from evaluation of the XPath expression
contained by the
@measure
attribute on
the unit division rule. Such unit
division rules specify an empty collection
of numerator measures.
This section defines the processing model for a formula . The processing model is defined for a single evaluation of a single formula. Given a target XBRL instance, it MAY be possible to evaluate a formula in several different ways, using different combinations of information from that XBRL instance.
The input to a formula, referred to as the formula input is the target XBRL instance and values, supplied by the processing application, for any of the parameters that a formula is dependent on.
A prerequisite for a formula evaluation is an evaluation for the formula's variable set. Given a variable set evaluation, the formula evaluation entails: evaluating the formula expression.
If a formula can be evaluated to produce a fact value, the rules for constructing the the concept, context, unit and precision of that fact MAY also be evaluated to construct the information necessary to report the fact in an output XBRL instance.
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/2008/
- 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/2008/formula.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 including the participants in the Formula Working Group.
Date | Author | Details |
---|---|---|
18 December 2006 | Geoff Shuetrim |
First internal working draft created, drawing extensively on the previous formula specification drafts |
23 April 2007 | Geoff Shuetrim |
Added text to the formula processing model to clarify that a formula may be evaluated against an XBRL instance to produce more than one output fact. Changed the formula-concept relationship from a formula arc to a generic arc. |
24 April 2007 | Geoff Shuetrim |
Amended the processing model to move the bindAsSequence material to the variables specification and to introduce the material on comparison fact variables referencing the fact variable evaluation specification in the variables specification. This injects implicit filtering capabilities into formula evaluation. |
25 April 2007 | Geoff Shuetrim |
Added a date to the arcroles defined in the specification. Added XPath expression parameter declaration syntax. Added XPath custom function declaration syntax. |
02 May 2007 | Geoff Shuetrim |
Changed the unit and context rules and the accuracy rules to make greater use of references to fact variables. |
07 May 2007 | Geoff Shuetrim |
Removed the requirement that relationships be defined in terms of the concrete arcs that express them. |
08 May 2007 | Geoff Shuetrim |
Fixed the XPath reference to refer to the recommendation rather than a working draft. |
29 May 2007 | Geoff Shuetrim |
Changed references to decimal to decimals to be consistent with the XBRL 2.1 specification based on feedback from Herm Fischer. |
11 June 2007 | Geoff Shuetrim |
Added a validation error to cover situations where a formula contains a concept attribute and has formula-concept relationships. Moved the section on formula-concept relationships to be adjacent to the concept identification rule section. Reverted to an explicit ordering of evaluation for variables (and parameters) given the complex nature of the interaction between implicit orderings and implicit filtering. |
24 July 2007 | Hugh Wallis |
Edited for public working draft publication. |
07 November 2007 | Geoff Shuetrim |
Converted the specification to XML format. Added in the definitions and the hyperlinks to the relevant sections of the normative schema. Rewrote the abstract and introduction to provide better background on what formulae are intended to achieve. Re-introduced arcrole declarations into the normative schema, thus forcing all relationships defined in the formula specification to be expressed by generic arcs. Moved the parameter resource to the variable specification so that it can be used with variables without needing to involve formula evaluation. Moved the material on custom function signatures to the variable specification. Added material on reference variables to cover situations where the one formula has more than one fact variable with the same QName in its variable set. Changed the arcrole for relationships from formulae to concepts for output concept identification to correspond to the suggestions from Masatomo Goto. This made the text for the relationship more intuitive. |
12 November 2007 | Geoff Shuetrim |
Clarified the definitions relating to reference variables and both context and unit rules. Brought the wording of the text into line with the XML Schema constraints on the required usage of the reference variable for context rules and unit rules. Linked all of the external terminology references back to bibliographic citations. Added in a section on formula arcs for completeness.
Defined the context node for evaluation of formula preconditions
as the Included parameters as yet another kind of resource that can be related to a formula by a formula-variable relationship. |
13 November 2007 | Geoff Shuetrim |
Moved the definition of the target XBRL instance to the variable specification.
Moved the |
15 November 2007 | Geoff Shuetrim |
Added a section on implicit filters, tying the implicit filtering
scheme to the XLink |
20 November 2007 | Geoff Shuetrim |
Begun work on the segment OCC rules and scenario OCC rules to make them more capable with respect to explicit dimensions. |
21 November 2007 | Geoff Shuetrim |
Finished drafting of the OCC rules that cover both segment OCC rules and scenario OCC rules. |
26 November 2007 | Geoff Shuetrim |
Systematically incorporated the feedback from
Masatomo Goto. Added in error codes
to cover situations where the context rules
and the unit rules are inappropriately omitted.
Added in statement that Extended variable naming via formula-variable relationships to cover parameter naming. |
27 November 2007 | Geoff Shuetrim |
Moved the section on implicit filters back to the variable specification and expressed it in terms of a variable-set resource so that the notion of implicit filtering is available for variable usages going beyond formula evaluation. |
30 November 2007 | Geoff Shuetrim |
Fixed the reference variable definition based on feedback from Jim Richards. Added markup to enable specification of OCC rules for any kind of statically determined content of output segments and scenarios. |
03 December 2007 | Geoff Shuetrim |
Moved the accuracy rules to be a sub section of the value rules section. Simplified the expression of the accuracy rules by adding new definitions of explicit and implicit accuracy rules. Clarified that accuracy rules are only relevant when output facts are numeric items. Defined a default location rule so that aspect models correspond exactly to output models. Added a new error code to handle situations in which the reference unit for an explicit unit rule is missing. This replaces a non-numeric error code that was defined in slightly different terms. Eliminated duplicate definition of the term: output unit. Added a comment highlighting the anomaly of no footnote rules but having custom attribute rules. Replaced all references to formula variables with references to variables in a formula's variable set. This increases the usage that the formula specification makes of infrastructure in the variables specification. |
04 December 2007 | Geoff Shuetrim |
Restructured the OCC rules section to clarify the treatment of implicit and explicit aspect rules for OCC content. Clarified the distinction between an OCC and a segment or scenario. |
05 December 2007 | Geoff Shuetrim |
Added an error code to cover situations where a value expression produces a sequence with more than one item in it.
Specified that value expressions producing an empty sequence require
the output fact to be reported as nil, using the XML Schema Instance
Added a paragraph to the context rules section stating that implicit aspect rules take precedence over the matching of aspects based on the context rule, rather than its sub-rules. Added a paragraph to the unit rule section to cover the situation where the units in the numerator and the denominator exactly cancel. Added examples. |
07 December 2007 | Geoff Shuetrim |
Added comment about the need to reference implicit aspect values when defining explicit aspect values. |
08 December 2007 | Victor Morilla |
Corrected some typos and added comments. |
10 December 2007 | Geoff Shuetrim |
Addressed comments from Victor Morilla regarding
misleading implication of a default value for the Added sentences to the section on location rules to clarify that they are not expressed by additional markup in formula and to clarify that they prevent implicit filtering to determine the location of output aspects. These changes are intended to address comments from Victor Morilla. Clarified the non-existent reference variable error code conditions as suggested by Victor Morilla. As suggested by Victor Morilla, strengthened the error code relating to the use of variables that have evaluated to an empty sequence as reference variables for explicit aspect rules to ensure that the error can be detected prior to formula processing. |
16 December 2007 | Geoff Shuetrim |
Eliminated XLink based syntax for concept rules. Eliminated the syntax for custom output attributes. Eliminated the section on messages. Recast the output context and unit rules in terms of aspect rules, modifying the syntax of aspect rules as required. Simplified the integration of implicit filtering and uncovered aspects with aspect rules. Eliminated the section on location rules. Added a section on default aspect rules to enable succinct expression of aspect rules where output aspect rules are sufficiently straightforward. Clarified the section on accuracy rules to ensure that if a formula expresses its accuracy rule with a particular attribute, that attribute is also required to be used to report the output accuracy. |
17 December 2007 | Geoff Shuetrim |
Finalised the redrafting of aspect rules.
Based on feedback from Herm Fischer,
removed the arcrole type declaration from the normative schema.
and hanged the normative schema to allow the |
18 December 2007 | Victor Morilla |
Minor typographic corrections and reword of some sentences |
19 December 2007 | Geoff Shuetrim |
Enabled unit rules to force the SAV for the unit rule to be undefined. |
24 December 2007 | Geoff Shuetrim |
Addressed clarifications suggested by Roland Hommes:
clarified the application dependency of |
20 January 2008 | Geoff Shuetrim |
Fixed up the XML Schema error in the |
24 January 2008 | Geoff Shuetrim |
Made the |
31 January 2008 | Geoff Shuetrim |
Standardised the format of the hyperlinks to the normative schema.
Removed the redundant Removed the duplicate row from the value expression example as suggested by Masatomo Goto. |
02 February 2008 | Geoff Shuetrim |
Corrected a grammatical error in the explanation of source aspect values. Corrected a grammatical error in the explanation of OCC dimension rules. |
03 February 2008 | Geoff Shuetrim |
Corrected missing RFC2119 tags around a MUST NOT statement. Referenced the variables specification from within the abstract. |
05 March 2008 | Geoff Shuetrim |
Added an example to motivate the conflictingAspectRules error. |
08 March 2008 | Geoff Shuetrim |
Clarified the definition of the aspect addressed by an aspect rule by removing the wording relating to assistance of applications.
Explicitly specified that the Added explicit markup for the OCC rules in the example showing how they work. Added examples to make the unit aspect rules more accessible. Added footnotes to the headings in the unit rule example table to make them more informative. Added new cases to the OCC fragment rule example to illustrate that OCC fragment rules are not only applicable to XDT dimension content. These changes were suggested by Paul Bull. |
13 March 2008 | Geoff Shuetrim |
Removed the potentially ambiguous or misleading terms "transformed" and "XBRL report" from the introduction. Reworded the introduction to output fact accuracy to clarify that it is not imposing any new constraints. Clarified the explanation of the xbrlfe:illegalUseOfUncoveredQName error and defined the term implied SAV to improve the explanation of the usage of the uncovered QName. Removed a misleading MAY from the introduction to the section on default aspect values. Removed a misleading sentence from the section on period aspect rules stating that period RAVs are variations on period SAVs. Added an explicit reference to the Implicit filter specification. These changes were suggested by CompSci Resources. |
20 March 2008 | Geoff Shuetrim |
Fixed broken hyperlinks. |
01 April 2008 | Geoff Shuetrim |
Fixed the first period rule example to get the time and date adjustments correct for instants. |
07 April 2008 | Geoff Shuetrim |
Added a paragraph clarifying that a source in a formula can be
the source defined by a |
23 April 2008 | Geoff Shuetrim |
Clarified that when a set of output OCC content has been identified by XPath or Fragment OCC rules and that content contains XDT dimensions, those dimensions need to be taken into account when determining what XDT dimension output aspect values to determine from source aspect values. This addresses an ambiguity identified by Andy Harris. |
07 August 2008 | Geoff Shuetrim |
Improved cross references to terminology used in the OCC rules section. Replaced all usages of "OCC aspect rule" with the defined term: "OCC rule". Restructured the definition of segment and scenario OCC rule sets to put the terms being defined first rather than last in the definitions. |
12 August 2008 | Geoff Shuetrim |
Corrected the interpretation of omitted segments and scenarios to ensure appropriate recognition of default XDT dimension values. |
14 August 2008 | Geoff Shuetrim |
Corrected previous editing errors made in relation to the duplicate definition of the scenario OCC rule set. Changed defined terminology for OCC rules to make each rule have a name following the structure xxx OCC rule rather than OCC xxx rule. Made this consistent throughout the text of the specification. Removed the augment attribute on OCC rules, replacing it with an empty OCC rule that converts any original OCC into an empty subsequent OCC. |
25 August 2008 | Geoff Shuetrim |
Redesigned OCC rules to only operate on the content remaining in segment and scenario elements after the content relating to other aspects in the relevant aspect model have been removed. The dimension aspect rules have been changed accordingly so that they are not OCC rules. This simplification makes it easier to work with dimension aspects (now that we do not have segment and scenario dimension aspects). |
04 September 2008 | Geoff Shuetrim |
Changed the base type for the segment/scenario enumeration to xs:token instead of xs:string to achieve consistency with other enumeration definitions in the normative schemas. This was suggested by Roland Hommes. |
08 September 2008 | Geoff Shuetrim |
Added in typed dimension rules to enable formula control of output typed dimension values. This was required, as suggested by Andy Harris, now that OCC rules and dimension rules are separate. The element name for the explicit dimension rule has changed accordingly. Defined a new error code to correspond to the existing normative constraints on the legal results obtaining from evaluating the XPath expression in an XPath OCC rule. |
24 October 2008 | Geoff Shuetrim |
Deleted the |
14 November 2008 | Geoff Shuetrim |
Made the abstract dimension aspect element really abstract. Corrected references to the XDT specification to use the correct ID. |
17 November 2008 | Geoff Shuetrim |
Made the |
15 December 2008 | Geoff Shuetrim |
Updated references to the latest errata-corrected version of the XBRL 2.1 specification. |
This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International Formula Working Group up to and including 31 December 2008. Hyperlinks to relevant e-mail threads may only be followed by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.
No errata have been incorporated into this document.