1 Introduction

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.

Example 1: Formula as documentation of a stock-flow relationship

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.

Example 2: Formula to produce current ratio 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.

Example 3: Formulae producing nonsense output

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.

1.1 Background

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.

1.2 Relationship to other work

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.

1.3 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

1.4 Terminology

This specification is consistent with the definitions of any of the terms defined in specifications that it depends on.

1.5 Document conventions (non-normative)

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

1.6 Namespaces and namespace prefixes

Namespace prefixes [XML NAMES] will be used for elements and attributes in the form ns:name where ns is the namespace prefix and name is the local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces is consistent with Table 1.

The prefix column in Table 1 is non normative. The namespace URI column is normative.

Table 1: Namespaces and namespace prefixes

Prefix	Namespace URI
`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/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`
`iso4217`	`http://www.xbrl.org/2003/iso4217`

1.7 XPath usage

XPath usage is identical to that in the XBRL Variables Specification [VARIABLES].

2 Syntax

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.

2.1 Formulae

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:

the value of output facts (Section 2.1.1)
the accuracy of numeric output facts (Section 2.1.1.1)
the aspects of output facts (Section 2.1.2)

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.

2.1.1 Value rules

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.

Example 4: Value expressions

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

2.1.1.1 Accuracy rules

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.

Example 5: Accuracy rules

Decimals rule XPath expression	Precision rule XPath expression	Output fact value	Output accuracy
Omitted	Omitted	1000000	`@precision=0`
-6	Omitted	1000000	`@decimals=-6`
omitted	1	1000000	`@precision=1`

2.1.2 Aspect rules

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.

2.1.2.1 Required aspect values and sources

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.

A segment SAV is a SAV that is reported by a segment or by the absence of a segment.

A scenario SAV is a SAV that is reported by a scenario or by the absence of a scenario.

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:

Select any one of the formula's fact variables that does not have a filter that covers the aspect that is addressed by the aspect rule and that has been evaluated to a sequence that is not empty.
Select any one of the facts in the sequence of facts that the chosen fact variable has evaluated to.
The implied SAV, if it is defined, is the value of the aspect that is addressed by the aspect rule, for the chosen fact.

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:

Select the fact variable with the QName equal to that contained by the source.
Select any one of the facts in the sequence of facts that the chosen fact variable has evaluated to.
The implied SAV, if it is defined, is the value of the aspect that is addressed by the aspect rule, for the chosen fact.

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.

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.

Example 6: Nearest sources

<formula:formula xlink:type="resource" xlink:label="formula" implicitFiltering="true" aspectModel="dimensional" source="eg:variableA">

<formula:aspects>

<formula:entityIdentifier value="'ABCD-1234'"/>

</formula:aspects>

<formula:aspects source="eg:variableB">

<formula:period/>

<formula:unit source="eg:variableC">

<formula:multiplyBy source="eg:variableD"/>

</formula:unit>

</formula:aspects>

</formula:formula>

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.

2.1.2.2 Default aspect rules

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.

2.1.2.3 Concept rules

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.

Example 7: Dynamic concept rules

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

2.1.2.4 Entity identifier rules

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.

Example 8: Entity identifier rules

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.

2.1.2.5 Period rules

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.

Example 9: Period rules

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

2.1.2.6 Open context component rules

An open context component (OCC), is a set of aspect values expressed by a segment or scenario or by the absence of a segment or scenario.

An OCC aspect, is an aspect with a value that is reported as part of an OCC.

All contexts have two OCCs: one corresponding to the segment and one corresponding to the scenario. This is the case, even if a context omits its segment or scenario.

A segment OCC is the OCC for a segment.

A scenario OCC is the OCC for a scenario.

If the segment is omitted from a context then the context's segment OCC is an empty sequence. If a segment OCC is an empty sequence, then it MUST be represented in a context by omitting the segment.

If the scenario is omitted from a context then the context's scenario OCC is an empty sequence. If a scenario OCC is an empty sequence, then it MUST be represented in a context by omitting the scenario.

The aspects that can be given values in an OCC depend upon the aspect model that is being used to interpret the content of segments and scenarios.

If a variable set uses the dimensional aspect model then its segment OCC can only include values for segment dimension aspects and non-XDT segment aspects.

Likewise, its scenario OCC can only include values for scenario dimension aspects and non-XDT scenario aspects.

If a variable set uses the non-dimensional aspect model then its segment OCC can only include values for complete segment aspects.

Likewise, its scenario OCC can only include values for complete scenario aspects.

If a variable set uses some other aspect model, that other aspect model will specify the aspects that can be in segment OCCs and scenario OCCs.

An output OCC, is an OCC of the output fact.

An OCC rule, is an aspect rule that addresses an aspect with a value in an OCC and that is in the substitution group for the <formula:abstract.occ.aspect> element.

If the @occ attribute on an OCC rule equals segment then that OCC rule determines the output value of an aspect that is reported in a segment.

A segment rule is an OCC rule with an @occ attribute equal to segment.

If the @occ attribute on an OCC rule equals scenario then that OCC rule determines the output value of an aspect that is reported in a scenario.

A scenario rule is an OCC rule with an @occ attribute equal to scenario.

A formula MAY contain more than one segment rule and more than one scenario rule.

The OCC aspect rules that are segment rules form a set of OCC aspect rules that are evaluated together to determine output segment OCCs. Such a set is a segment OCC aspect rule set.

Aspect rules in a segment OCC aspect rule set address the set of aspects that are given values in the output segment OCC that is constructed by applying them.

The OCC aspect rules that are scenario rules form a set of OCC aspect rules that are evaluated together to determine output scenario OCCs. Such a set is a scenario OCC aspect rule set.

Aspect rules in a scenario OCC aspect rule set address the set of aspects that are given values in the output scenario OCC that is constructed by applying them.

The aspect rules in a segment or scenario aspect rule set MUST be processed in document order.

An original OCC is the OCC that is modified by application of an OCC aspect rule.

The subsequent OCC is the OCC resulting from applying an OCC aspect rule to an original OCC.

The subsequent OCC for an OCC aspect rule is the original OCC for the OCC aspect rule that is processed next.

The RAVs specified by a segment or scenario aspect rule set are those aspect values in the subsequent OCC for the last OCC aspect rule processed in a segment or scenario OCC aspect rule set.

If the first OCC fragment or XPath rule to be processed contains an @augment attribute with a value of false, then the original OCC is the empty set of aspect values.

Error code xbrlfe:innappropriateAugmentAttribute MUST be thrown if an OCC fragment or XPath rule is not the first OCC fragment or XPath rule to be processed and has an @augment attribute.

If the @augment attribute equals true or is omitted on the first OCC aspect rule in a segment OCC aspect rule set to be processed, then the original OCC contains the set of segment SAVs. If a source is not defined, then the original OCC is the empty set.

If the @augment attribute equals true or is omitted on the first OCC aspect rule in a scenario OCC aspect rule set to be processed, then the original OCC contains the set of scenario SAVs. If a source is not defined, then the original OCC is the empty set.

The following sub-sections define the syntax and semantics for three OCC aspect rules. Extension specifications MAY define other OCC aspect rules.

2.1.2.6.1 OCC fragment rules

An OCC fragment rule is an OCC aspect rule that is expressed by the <formula:occFragments> element.

An OCC fragment rule extends an original OCC by appending its child elements (and their descendants, if any) to obtain a subsequent OCC.

Example 10: OCC fragment rules

Original OCC	Child elements of the OCC fragment rule	Subsequent OCC¹
	<eg:budget/>	<eg:budget/>
<eg:confidential/>	<eg:audited/>	<eg:confidential/> <eg:audited/>
<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember>	<xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>	<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember> <xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>
	<xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>	<xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>
<eg:audited/>	<xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>	<eg:audited/> <xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>

1. The subsequent OCCs presume that the first OCC rule in each OCC rule set has the @augment attribute equal to true.

2.1.2.6.2 OCC XPath rules

An OCC XPath rule is an OCC aspect rule that is expressed by the <formula:occXPath> element.

An OCC XPath 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 to obtain a subsequent OCC.

The context item for evaluation of the XPath expression contained by an OCC XPath rule is the <xbrli:xbrl> element of the target XBRL instance.

2.1.2.6.3 OCC dimension rules

An OCC dimension rule is an OCC aspect rule that is expressed by the <formula:occDimension> element.

OCC dimension rules specify RAVs for segment dimension aspects or scenario dimension aspects.

OCC dimension rules specify a segment or scenario dimension aspect value explicitly, or by reference to a SAV.

The dimension, affected by an OCC dimension rule is specified by the QName in the @dimension attribute on the OCC dimension rule.

If an OCC dimension rule contains no child elements, then the OCC dimension rule specifies that the subsequent OCC MUST include a dimension aspect value for the dimension identified by the OCC dimension rule. It also specifies that the value for that dimension aspect MUST be the SAV for that dimension aspect.

Error code xbrlfe:missingSAVForDimensionRule MUST be thrown if an OCC dimension rule does not have any child elements and does not have a SAV for the dimension that it identifies with its @dimension attribute.

If an OCC dimension rule contains a <formula:member> element, 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 OCC dimension rule contains a <formula:member> element, then the subsequent OCC for the dimension OCC aspect rule MUST include a dimension aspect value for the specified dimension with the value specified by the <formula:member> element.

If an OCC dimension rule contains a <formula:omit> element then the dimension identified by the dimension OCC aspect rule MUST NOT have a value in the subsequent OCC for the OCC dimension rule.

If the original OCC has a value for a dimension named by an OCC dimension rule, then that value MUST be overwritten, as necessary, to satisfy the requirements imposed by the OCC dimension rule.

Example 11: OCC Dimension rules

Original OCC	OCC Dimension rule	Subsequent OCC
<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember>	Add explicit dimension `eg:ProductDim` with value `eg:Cars`: <formula:occDimension dimension="eg:ProductDim"> <formula:member> eg:Cars </formula:member> </formula:occDimension>	<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember> <xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember>
<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember>	Add segment dimension `eg:ProductDim` with value of that segment aspect for the fact that variable `eg:factVariableA` has evaluated to: <formula:occXpath dimension="eg:ProductDim" select="xfi:fact-explicit-segment-dimension-value($eg:factVariableA)"/>	<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember> <xbrldi:explicitMember dimension="eg:ProductDim"> eg:Cars </xbrldi:explicitMember> This presumes that fact variable `eg:factVariableA` evaluated to a fact with a value of `eg:Cars` for dimension `eg:ProductDim`.
<xbrldi:typedMember dimension="eg:dCustomer"> <eg:cust> 12345 </eg:cust> </xbrldi:typedMember>	Omit dimension `eg:dCustomer` <formula:occDimension dimension="eg:dCustomer"> <formula:omit/> </formula:occDimension>

2.1.2.7 Unit rules

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.7.1) and unit division sub-rules (See Section 2.1.2.7.2).

The RAV for a unit rule is obtained by the following sequence of steps:

Combine the collections of numerator measures for the unit multiplication rules with the collections of denominator measures for the unit division rules to obtain a single collection of numerator measures. Augment this single collection of numerator measures with the numerator measures of the unit rule's SAV, if one is defined, to obtain the set of all numerator measures.
Combine the collections of denominator measures for the unit multiplication rules with the collections of numerator measures for the unit division rules to obtain a single collection of denominator measures. Augment this single collection of denominator measures with the denominator measures of the unit rule's SAV, if one is defined, to obtain the set of all denominator measures.
Eliminate, from the numerator and denominator measure collections, any pairs of measures that specify the same QName where one member of the pair is in the collection of numerator measures and the other member of the pair is in the collection of denominator measures.

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.

Example 12: Unit rules

Implicit measures¹		Reference measures²		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.

2.1.2.7.1 Unit multiplication rules

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.

2.1.2.7.2 Unit division rules

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.

3 The processing model for formulae

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.

Appendix A Normative schema

The following is the XML schema provided as part of this specification. This is normative. Non-normative versions (which should be identical to these except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.

NOTE: (non-normative) Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows:

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

</choice>

</complexType>

</choice>

</sequence>

</extension>

</complexContent>

</complexType>

</element>

</sequence>

</complexType>

</element>

</complexType>

</choice>

</extension>

</complexContent>

</complexType>

</element>

</extension>

</complexContent>

</complexType>

</element>

</element>

</complexType>

</element>

</complexType>

</element>

</choice>

</extension>

</complexContent>

</complexType>

</element>

</complexType>

</element>

</complexType>

</element>

</sequence>

</extension>

</complexContent>

</complexType>

</element>

</restriction>

</simpleType>

</attribute>

</extension>

</complexContent>

</complexType>

</sequence>

</extension>

</complexContent>

</complexType>

</element>

</extension>

</complexContent>

</complexType>

</element>

</extension>

</complexContent>

</complexType>

</element>

</choice>

</extension>

</complexContent>

</complexType>

</element>

</schema>

Appendix B References

DIMENSIONS: XBRL International Inc.. "XBRL Dimensions 1.0"
Ignacio Hernández-Ros, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm)
IETF RFC 3986: IETF (Internet Engineering Task Force). "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"
T. Berners-Lee, R. Fielding, and L. Masinter.
(See http://www.ietf.org/rfc/rfc3986.txt)
IMPLICIT FILTERS: XBRL International Inc.. "XBRL Implicit Filters 1.0, Public Working Draft"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See ../../implicitFilters/CR-2008-03-28/implicitFilters-CR-2008-03-28.html)
VARIABLES: XBRL International Inc.. "XBRL Variables 1.0, Public Working Draft"
Phillip Engel, Herm Fischer, Victor Morilla, Jim Richards, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See ../../variables/CR-2008-03-28/variables-CR-2008-03-28.html)
XBRL 2.1: XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1"
Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2006-12-18.htm)
XML NAMES: W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Second Edition)"
Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin.
(See http://www.w3.org/TR/REC-xml-names/)
XML SCHEMA DATATYPES: W3C (World Wide Web Consortium). "XML Schema Part 2: Datatypes Second Edition"
Paul V. Biron, and Ashok Malhotra.
(See http://www.w3.org/TR/xmlschema-2/)
XML SCHEMA STRUCTURES: W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/xmlschema-1/)
XPATH 2.0: W3C (World Wide Web Consortium). "XML Path Language (XPath) 2.0"
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández, Michael Kay, Jonathan Robie, and Jérôme Siméon.
(See http://www.w3.org/TR/xpath20/)

Appendix C Intellectual property status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

This document and the information contained herein is provided on an "AS IS" basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (www.xbrl.org/legal).

Appendix D Acknowledgements (non-normative)

This document could not have been written without the contributions of many people including the participants in the Formula Working Group.

Appendix E Document history (non-normative)

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 `<xbrli:xbrl>` element of the target XBRL instance. 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 `@bindEmpty` attribute and the `@bindAsSequence` attribute from the formula arc to the general and fact variable resources. This means that classification of variables as being able to bind to empty sequences and being able to bind to non-singleton sequences is within scope for the variable specification. This is important because such classification is useful outside the scope of formulae. For example, it will be useful in the XBRL instance validation usage pattern where variables are used directly rather than as components of a formula for testing the existence or otherwise of certain classes of facts in XBRL instances.
15 November 2007	Geoff Shuetrim	Added a section on implicit filters, tying the implicit filtering scheme to the XLink `@xlink:role` attribute value on the formula resource.
20 November 2007	Geoff Shuetrim	Begun work on the segment and scenario 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 and scenario 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 `@id` attribute values on output contexts and units are processor dependent. 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 `@xsi:nil` attribute. 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 `@implicitFiltering` attribute on formulae. 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 `<formula:aspects>` element to be omitted from formulae.
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 `@id` attributes; provided a reference for the term "aspect" in the definition of output aspects; removed the redundant output location definition; clarified the usage of the term "nil" in Example 4; and simplified the usage of the `<formula:omit>` element in OCC dimension rules.
20 January 2008	Geoff Shuetrim	Fixed up the XML Schema error in the `<formula:occDimension>` element caused by not using a global complexType definition for the type of the element that is its parent in the substitution group hierarchy.
24 January 2008	Geoff Shuetrim	Made the `@dimension` attribute required in the normative schema for the `<formula:abstract.occ.dimension.aspect>` element and those elements in its substitution group. This brings the normative schema into line with the text of the specification.
31 January 2008	Geoff Shuetrim	Standardised the format of the hyperlinks to the normative schema. Removed the redundant `<formula:attribute>` element from the normative schema as suggested by Masatomo Goto. 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 `@select` attribute on OCC XPath rules contains the XPath expression to be evaluated. Also clarified the context node for evaluation of such XPath expressions. Added explicit markup for the OCC aspect 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.

Appendix F Errata corrections in this document

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

Formula 1.0

Candidate Recommendation 28 March 2008

Status

Abstract

Table of Contents

Appendices

Table

Examples

Definitions

Error codes

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 Open context component rules

2.1.2.6.1 OCC fragment rules

2.1.2.6.2 OCC XPath rules

2.1.2.6.3 OCC dimension rules

2.1.2.7 Unit rules

2.1.2.7.1 Unit multiplication rules

2.1.2.7.2 Unit division rules

3 The processing model for formulae

Appendix A Normative schema

Appendix B References

Appendix C Intellectual property status (non-normative)

Appendix D Acknowledgements (non-normative)

Appendix E Document history (non-normative)

Appendix F Errata corrections in this document