Formula Specification Requirements
Public Working Draft dated 2007-07-13
Copyright © 2006-7, XBRL International Inc., All Rights Reserved

This version:
	Formula-REQ-PWD-2007-07-13.rtf
is normative. Any other formats and versions are non-normative
Editors
Walter Hamscher	walter@hamscher.com	Standard Advantage / PricewaterhouseCoopers	
Geoff Shuetrim	geoff@galexy.net	Galexy Pty. Limited	
Contributors
David vun Kannon	david.k.vun.kannon@us.pwc.com	PricewaterhouseCoopers	
Participants in the Formula Working Group have comprehensively reviewed the Candidate Recommendation Formula Requirements published on 21 May, 2005 [CRFR]., in light of, more recent innovations such as the Dimensions Specification.
Abstract
This document is derived from the Candidate Recommendation Formula Requirements published on 21 May, 2005 [CRFR].  Requirements are now documented in some detail, including motivating use-cases and links to formula working group mailing list threads where those are available.
Status
Circulation of this Public Working Draft is unrestricted.  Recipients of this draft are invited to submit comments to Geoff Shuetrim, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
Formula Specification Requirements
Public Working Draft dated 2007-07-13
Copyright © 2006-7, XBRL International Inc., All Rights Reserved
1	Terminology and Formatting
2	Requirements
2.1	Specification modularity requirements
2.2	The nature of formulae
2.3	Formulae and the DTS
2.4	Formula documentation
2.5	Formula syntax
2.6	Formula processing
2.7	Formula expressions
2.8	Formula signalling
2.9	Variable binding
A.	References (non-normative)
B.	Intellectual Property Status (non-normative)
C.	Acknowledgements (non-normative)
D.	Approval process (non-normative)
E.	Document history (non-normative)

1	Terminology and Formatting
Terminology used in XBRL frequently overlaps with terminology from other fields.  Refer to the XBRL 2.1 Specification [XBRL] for definitions of specific terms.  Additional specific terminology is defined in the following table.
target instance	The XBRL instance being processed by a formula processor.  It MUST be valid according to the XBRL 2.1 specification.	
binding	The association of values with variables in expressions.	
filtering	The process of determining the set of bindings that are permitted for a variable, given the inputs to the formula processor, the formula being processed, and previous variable bindings	

The following highlighting is used for non-normative examples in this document:
	
Non-normative editorial comments to be removed from final recommendations are denoted as follows:
GCS: This highlighting indicates editorial comments about the current draft, prefixed by the editor’s initials.
Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
2	
Requirements
2.1	Specification modularity requirements
2.1.1	Any specifications MUST NOT redefine terms defined in specifications upon which they depend
2.1.1.1	Mailing list thread: http://tinyurl.com/w98pm
2.1.1.2	Motivation
This requirement is imposed to make sure that specifications supporting the use of formulae in XBRL are expressed using a language that is consistent with the specifications on which it depends.
2.1.2	Any document that is conformant with specifications produced by the working group will also be a valid XBRL 2.1 document
2.1.2.1	Mailing list thread: http://tinyurl.com/y79dv3
2.1.2.2	Motivation
This requirement is imposed to make sure that specifications supporting the use of formulae in XBRL only define syntax that is valid according to the XBRL 2.1 specification.  This ensures that all documents that include formula definitions will be deemed valid by an XBRL 2.1 conformant processor.
2.1.3	Any valid XBRL 2.1 document will also be conformant with specifications produced by the working group
2.1.3.1	Mailing list thread: http://tinyurl.com/yw3ha2
2.1.3.2	Motivation
This requirement is imposed to make sure that specifications supporting the use of formulae in XBRL treat all valid XBRL 2.1 documents as being conformant.  This ensures that such specifications do not prohibit the use of any syntax that is permitted by the XBRL 2.1 specification.
2.2	The nature of formulae
2.2.1	Formulae MUST define functional relationships between XBRL objects that are held to be true across XBRL instances
2.2.1.1	Mailing list thread: http://tinyurl.com/y9dzzl
2.2.1.2	Motivation
This requirement has been included to ensure that formulae are designed to be able to express functional relationships that can be applied to different XBRL instances.  The results of applying formulae to the different instances will depend on the content of those instances but the nature of the relationships expressed by formulae will be consistent regardless of the XBRL instance that the relationships are applied to.
2.2.2	Formulae MUST be able to test for the presence or absence of various properties of the target instance
2.2.2.1	Mailing list thread: http://tinyurl.com/y43g9f
2.2.2.2	Motivation
Properties are deemed to include:
•	the presence of specified facts or sets of facts, where those facts are identified by a complete or partial set of constraints on their aspects (eg: entity, period, scenario, segment, unit, tuple structure); and
•	the association of footnotes with facts that are identified by a complete or partial set of constraints on their aspects.
For additional details see the documentation of requirements pertaining specifically to XBRL instance validation [XIVR].
2.2.3	[REJECTED]It MUST be possible to express a formula that can be used to produce XBRL facts for different concepts
2.2.3.1	This requirement has been rejected by the formula working group because of concerns about the potential for unintended adverse impacts of the wording on the documentation implications of formula designs that address this requirementMailing list thread: http://tinyurl.com/y6pxuz
2.2.3.2	Motivation
This requirement was proposed to ensure that the formula specification provided for formulae where the concept aspect of the XBRL facts produced by formula execution is a function of the formula inputs.
e.g.: A formula is required to express the notion that the projected values of all facts in a balance sheet for the next year are equal to 1.2 times the amount for those facts as reported for the current year.
e.g.: A formula is required to express the notion that the total values across regions can be obtained by summing the values of the relevant facts for each region (where the aspects for the facts being summed and for the total fact being derived are identical except for the aspect determining the region being reported for).
2.2.4	[REJECTED] The output of formula processing MUST include 0, 1 or more XBRL instances
This requirement has been rejected on the basis that it does not impose any constraints on the formula specification.
2.2.4.1	Mailing list thread: http://tinyurl.com/33g3du
2.2.4.2	Motivation
This requirement is vacuous as it stands.  It was originally intended to capture the notion that formulae should express mappings from the data available from the input XBRL instance to XBRL facts.  It was broadened to be a mapping to XBRL instances rather than facts to accommodate designs where a single formula fully specified an output XBRL instance.  The wording was changed from MUST be able to generate an instance to must include zero or more to avoid the situation where a formula would always have to be able to produce XBRL facts (in an instance).
Note that this requirement is specifically not intended to rule out the generation of diagnostic information generated during evaluation of a formula.  Nor is it intended to rule out execution of a formula to generate information that is a subset of that required to produce a complete XBRL fact.  Thus, it is not intended to rule out using a formula to compute a fact value without also computing all of the associated and supporting aspects of that fact value.
2.2.5	Formulae MAY define functional relationships where facts for the same concept are used both as inputs and as outputs
2.2.5.1	Mailing list thread: http://tinyurl.com/y8o6jm
2.2.5.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL support the following kinds of formulae.
e.g.: A formula that defines estimated total assets for the next year as a constant growth rate applied to actual total assets reported for the current year.
e.g.: A formula states that fact z = f(z) where z represents a fact for a given configuration of aspects and f(.) represents some function.  Note that the process of finding a value of z that satisfies such a relationship MAY require iterative techniques.
2.2.6	Formulae MAY define functional relationships that, when evaluated, draw on values for facts that have different contexts and units
2.2.6.1	Mailing list thread: http://tinyurl.com/ymef71
2.2.6.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL support the following kinds of formulae.
e.g.: A formula computes a growth rate for sales as the percentage change in sales between the current and previous period.
e.g. A formula computes the end-of-period stock of cash as the beginning stock of cash plus the gross inflow of cash less the gross outflow of cash.
e.g.: A formula computes average shares for a period as the average of shares outstanding at the beginning of the period and shares outstanding at the end of the period.
2.2.7	Formula declarations MUST include sufficient information to support reporting the result of a successful evaluation as a complete XBRL item, including the item value, the concept, the context for the item, the units for the item, and the precision or decimals value for numeric items
2.2.7.1	Mailing list thread: http://tinyurl.com/y5u3ub
2.2.7.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL require formulae to be complete statements of the rules necessary to generate XBRL facts.  This is deemed to be important because it ensures that formulae can be executed in a manner that supports generation of output that can be used as the input of a subsequent formula processing.
This is of particular value in being able to chain together formulae to express more complex relationships.
e.g.: One formula expresses the relationship: Total assets = Current assets + Non-current assets.  A second formula expresses the relationship: Total liabilities = Current liabilities + Non-current liabilities.  A third formula expresses the relationship that equity = total assets + total liabilities.  The three formulae need to be chained together to enable derivation of equity from current and non-current assets and liabilities.
Note that this requirement does not imply that processors have to make use of the information required to construct a complete XBRL fact.
2.2.8	XBRL facts resulting from formula evaluation MAY have contexts and units that are not part of the target instance
2.2.8.1	Mailing list thread: http://tinyurl.com/vjnjk
2.2.8.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL provide a means of deriving facts with aspects that are not already specified in the instant input.
e.g.: A movement analysis for cash where the end of period cash is derived from an instance that only reports the beginning of period cash and the gross flows over the period.  Such an instance does not contain a context for the end period instant.
2.2.9	Formulae MUST be able to produce any valid value for any XBRL fact
2.2.9.1	Mailing list thread: http://tinyurl.com/w7nkm
2.2.9.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL to derive facts that are items or tuples and with any of the values that that can be supported by the concept content models expressible using XML Schema, including nill facts and fraction facts (with values that include a separate numerator and denominator).
e.g.: A formula specifies that the interest cover ratio be computed as a nill value if the denominator of the ratio or the numerator of the ratio is negative.
e.g.: See the documentation of Tuple Creation Requirements [TCR].
e.g.: A formula specifies that a new tax rate is determined as being 1 cent in the dollar more than the previous tax rate, which, itself, was expressed using a fraction item equal to 20 / 100.
2.2.10	Formulae MUST be able to include preconditions that determine whether the formula itself is to be evaluated
2.2.10.1	Mailing list thread: http://tinyurl.com/ydxnhz
2.2.10.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL include syntax for expressing preconditions that are to be tested against data an XBRL instance before a formula is executed against that data in the XBRL instance.
e.g.: The maximum allowable write-down depends on the purchase date of an asset. A formula for computing the amount of a write-down needs to condition on the purchase date of the asset because it is not a valid derivation for some date ranges.
2.2.11	Formula evaluation preconditions MUST not condition on the content of the output XBRL instance
2.2.11.1	Mailing list thread: None.  This is a positive version of a previously rejected requirement.
2.2.11.2	Motivation
This requirement is intended to simplify the implementation of formula processors by limiting the scope of the data that needs to be available when evaluating a formula and by eliminating dependencies between formula evaluations.
2.2.12	A DTS MUST be able to contain more than one formula that can be evaluated to compute facts for the one concept
2.2.12.1	Mailing list thread: http://tinyurl.com/stmxp
2.2.12.2	Motivation
Authors may write formulae that provide multiple ways of deriving a given fact.
e.g.: Total assets = current assets + non current assets.  Total assets = equity + total liabilities.  Both are valid and useful formulae.
2.3	Formulae and the DTS
2.3.1	A DTS MUST be able to include formulae
2.3.1.1	Mailing list thread: http://tinyurl.com/y82su3
2.3.1.2	Motivation
This requirement is included to ensure that specifications supporting the use of formulae in XBRL use the syntax of XBRL 2.1 valid extended links so that a set of formulae can be identified by their inclusion in a DTS.
Note that this rules out a syntax that allowed formulae to reference external XQuery modules.
2.3.2	The input DTS to a formula processor MUST include the DTS that is discoverable from the XBRL instance being processed
2.3.2.1	Mailing list thread: http://tinyurl.com/y82su3
2.3.2.2	Motivation
This requirement is included to ensure that the DTS providing context for formula evaluation also provides sufficient documentation of the information contained in the XBRL instance being processed.
2.3.3	Formulae, constant declarations, and function declarations MAY be partitioned into sets
Note that the use cases do not motivate the partitioning of functions and constants.  The use case (ostensibly for partitioning functions), appearing in the previous requirements document, does not actually motivate the requirement.  It just shows two formulae, each referencing a different function.  I think it would be better just to require uniquely named functions, based on the usual QName structure for function names.
2.3.3.1	Mailing list thread: http://tinyurl.com/yf2s55
2.3.3.2	Motivation
This requirement is included to ensure that users are able to partition two incompatible formulae.
e.g.: There are two methods for computing earnings per share, one based on division by average shares outstanding over the period and one based on division by end of period shares outstanding.  Only one of the two methods should be used to derive earnings per share when executing a set of formulae.  Being able to separate the two formulae into different sets enabling only one set to be executed can facilitate this level of control.  Note that it would also be possible to resolve the issue in this example by having two different earnings per share concepts, corresponding to the two different measurement approaches.
e.g.: A user of a formula link wants to execute only three of the formulae that are defined in the DTS to derive specific values that are inputs to their financial model.
e.g.: A user of a formula link wants to execute only three of the formulae that are defined in the DTS and only wants to execute those formulae for a specific period.  
2.3.4	Formulae in a DTS MUST be able to be prohibited
2.3.4.1	Mailing list thread: http://tinyurl.com/yfyxw7
2.3.4.2	Motivation
An extension to a set of formulae may need to introduce a modification to the relationship defined by an existing formula in the set being extended.  Prohibition of the original formula, thus ensuring that it is never executed, is necessary to ensure that the modified formula is the one that is used when the extension is applied.
2.4	Formula documentation
2.4.1	Formulae in a DTS MUST be able to be documented using labels
2.4.1.1	Mailing list thread: http://tinyurl.com/ydquxz
2.4.1.2	Motivation
Formulae will be part of the metadata that can be represented in an XBRL DTS.  In keeping with the other metadata in such a DTS, formulae will need human readable labels.
2.4.2	Formulae MUST be able to have multiple labels, with different purposes and in different languages
2.4.2.1	Mailing list thread: http://tinyurl.com/ygtjov
2.4.2.2	Motivation
Formulae will be part of the metadata that can be represented in an XBRL DTS.  In keeping with the other metadata in such a DTS, formulae will need human readable labels that can have different purposes and that can be expressed in different languages.
2.4.3	Formulae MUST be able to be documented using references
2.4.3.1	Mailing list thread: http://tinyurl.com/ye823s
2.4.3.2	Motivation
Formulae will be part of the metadata that can be represented in an XBRL DTS.  In keeping with the other metadata in such a DTS, formulae will need references to authoritative literature.
2.5	Formula syntax
2.5.1	The syntax for formulae SHOULD NOT require redundancy
2.5.1.1	Mailing list thread: http://tinyurl.com/yj3hvh
2.5.1.2	Motivation
The requirement is motivated by analogy to the unit and context structures in XBRL instances.  By eliminating redundancy, formulae may be made easier to maintain and formulae may be less prone to errors induced by unintended discrepancies that arise as modifications are made to some but not all of the identical structures.
2.5.2	It MUST be possible to define constants outside of a specific formula
2.5.2.1	Mailing list thread: http://tinyurl.com/ybfufg
2.5.2.2	Motivation
Some constants (e.g.: Pi, the natural number, a given tolerance to be used in tests of equality, the minimum capital adequacy number) will be useful in a range of different formulae.  This requirement makes sure that such constants can be defined in one place and referenced by multiple formulae.
2.5.3	It MUST be possible to define constants with values that are built-in XML Schema data types
2.5.3.1	Mailing list thread: http://tinyurl.com/ykp9na
2.5.3.2	Motivation
Any value that is a built-in XML Schema data type can be a valid value of an XBRL fact, depending on how the content model for that fact is defined.  Because constants will often be used to specify values that will be used in operations that also involve fact values, it makes sense to be able to define constants that can take on all of the values in the same domain.
2.6	Formula processing
2.6.1	The result of applying formulas to an instance that is not XBRL-valid is not defined
2.6.1.1	Mailing list thread: http://tinyurl.com/yzxe2y
2.6.1.2	Motivation
This requirement simplifies the work involved in developing a formula processor because it limits the range of possible inputs that need to be handled in a consistent manner.
2.6.2	Formula processing MUST NOT take a Post Taxonomy Validation Infoset as an input
2.6.2.1	Mailing list thread: None.  This requirement is a negative form of a requirement that was rejected in the previous version of requirements.
2.6.2.2	Motivation
No post taxonomy validation information set has been agreed so the formula specification cannot impose a requirement on formula processors to create such a data structure as part of formula evaluation.
2.6.3	Formulae MUST NOT provide a syntax for specifying the location in the output XBRL instance of the facts that they can generate
2.6.3.1	Mailing list thread: None.  This requirement is a negative form of a requirement that was rejected in the previous version of requirements.
2.6.3.2	Motivation
This requirement simplifies the burden on processor development and the burden on formula authors by eliminating some of the areas where the output of formula processing is required to be identical.  The rationale for the simplification is that the ordering of the content within an XBRL instance is given no semantic meaning by the XBRL 2.1 specification.
Note that the formula specification does not cover tuple creation so it does not need to address issues of child ordering for tuples. An extension specification dealing with tuple creation would need to address such placement issues for content generated by execution of formulae.
2.6.4	Formula processor behaviour MUST be defined in the event of expression evaluation exceptions
2.6.4.1	Mailing list thread: http://tinyurl.com/2mfxw9
2.6.4.2	Motivation
This requirement is motivated by a desire for consistent behaviour of formula processors in the event that an expression evaluation generates an exception.
2.7	Formula expressions
2.7.1	The expression language MUST include operators to select nodes in the target instance
2.7.1.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.1.2	Motivation
This requirement is somewhat controversial because of the view that it is more appropriate to use XBRL functions to access the information contained in the target instance.  Any information that is not accessible using XBRL functions should not have any meaning under the XBRL 2.1 specification and so should not be relevant to formulae.
The original motivation for this requirement is that it is easier (from an implementation perspective) to permit such operations than it is to prohibit them.
2.7.2	The expression language MUST be able to express all constants from the value space of XML Schema primitive data types
2.7.2.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.2.2	Motivation
This requirement is another manifestation of the need to be able to use constants from the same domain as the values of facts that may be used as inputs or generated as outputs of formulae.
2.7.3	The expression language MUST be able to include variables that have values determined outside of the expression itself
2.7.3.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.3.2	Motivation
This requirement is motivated by the desire to be able to define a variable and then reference it, to access its value, from more than one expression in a single formula.
e.g.: A variable provides access to a total assets fact.  The value of that fact is accessed to determine the value of the fact produced by evaluation of the formula.  The context of that fact is accessed to determine the context for the fact produced by evaluation of the formula.
2.7.4	The expression language MUST support standard mathematical operators
Operators that MUST be supported are:
●	Addition and subtraction of values;
●	Division and modulus of values, both integer and real;
●	Multiplication of values;
●	Determine maxima and minima of a sequence of values;
●	All of the following relational operations, =, <, >, <=, >=, and != on numeric items and =, != on non-numeric items
More use cases are required for modulus operations and integer division operations.
2.7.4.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.4.2	Motivation
e.g.: 0001 illustrates usage of the +, - and = operators).
e.g.: Division operations are required by formulae constructing financial ratios such as interest cover, leverage, or price-earnings ratios.
e.g.: Multiplication operations are required by formulae that are constructing weighted averages.
e.g.: Maxima and minima operators/functions will simplify formulae that involve determination of the most extreme values in a sequence of such values.  An example would be a formula that determines the maximum or minimum size of a transaction from a series of journal entries.
e.g.: Obtain the maximum value of an insurance premium reported in an XBRL instance.
e.g.: Obtain the fact that contains the maximum value of an insurance premium reported in an XBRL instance.
e.g.: Relational operators will support formulae that test fact values against boundary conditions.
e.g.: The net tax obligation should be computed in a manner that results in a value reported to zero decimal places and where the adjustment simply truncates any digits after the decimal place.
e.g.: The net tax obligation is computed by multiplying the taxable income by the numerator of the tax rate fraction item and then dividing by the denominator of the tax rate fraction item, performing the division using integer division.
2.7.5	The expression language MUST support absolute value operations
Realistic use cases are required to support this requirement.  (see the modulus/modulo discussion thread)
2.7.5.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.5.2	Motivation

2.7.6	The expression language MUST support regular expressions
2.7.6.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.6.2	Motivation
e.g.: regular expression operators/functions will support formulae that operate on facts that do not have numeric values.  They will also support formulae that depend on complex matching criteria against entity identifiers or dimension codes.
2.7.7	The expression language MUST support string concatenation
2.7.7.1	Mailing list thread: This requirement has not yet been put to the mailing list
2.7.7.2	Motivation
e.g.: Many financial reporting taxonomies contain alternatives for marking up textual information, with some more general facts being usable as a less markup-intensive way to represent information that would otherwise require breaking up of the text information into a very large number of elements.  This kind of construct would enable the mapping between the single text element and the many component text elements to be described using a concatenation formula.
e.g.: Construct a single address fact by concatenating the components of the address.
e.g.: Construct a complete international phone number by concatenating the country and area code with the local number.
2.7.8	The expression language MUST support standard logical operators
2.7.8.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.8.2	Motivation
e.g.: A formula computes a financial ratio as the ratio of two other values if both values are positive and it computes the financial ratio as a nill value if either value is negative.
e.g.: A formula computes a boolean value indicating if one or the other of two specific facts are reported.
2.7.9	The expression language MUST support if/then/else expressions
2.7.9.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.9.2	Motivation
If then else structures are required to support conditionality in the kinds of formulae being developed.
e.g.: If a particular fact is in the instance, use it in the construction of a financial ratio, otherwise use a substitute.
e.g.: If a particular fact is missing in the instance, use a default value for that fact.
e.g.: If a particular fact is reported for a duration that is less than one year, use a process for annualising it's value, depending on whether it is an instant or duration concept.
2.7.10	The expression language MUST support determination of the maximum and minimum dates in context periods in the target instance
2.7.10.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.10.2	Motivation
e.g.: Relational operators also support formula preconditions that involve checks against certain maximum and minimum period limits to determine whether it is appropriate for a formula to be evaluated.
2.7.11	The expression language MUST support testing for the presence or absence of any fact in the target instance
2.7.11.1	Mailing list thread: http://tinyurl.com/yk3dd2
2.7.11.2	Motivation
See the XBRL Instance Validation Requirements [XIVR] for details of examples motivating this requirement.
2.8	Formula signalling
2.8.1	The behaviour of a formula processor MUST be defined by the formula specification in the case of an expression evaluation exception
The requirement is redundant – see requirement 2.6.4.
2.8.1.1	Mailing list thread: http://tinyurl.com/2ugrra
2.8.1.2	Motivation
2.9	
Variable binding
2.9.1	Variable bindings to facts MAY filter based upon their contexts
2.9.1.1	Mailing list thread: http://tinyurl.com/36652q
2.9.1.2	Motivation
This requirement is intended to ensure that formulae can select facts from the input XRL instance as inputs based upon information in the contexts of those facts.
e.g.: A formula is designed to only fire to compute total assets for entities that are identified by a particular entity identification scheme.
e.g.: Movement analysis formulae require fact selection based upon period relationships between the facts that are inputs to the formula.
2.9.2	Variable bindings to facts MAY filter based upon their units
2.9.2.1	Mailing list thread: http://tinyurl.com/36652q
2.9.2.2	Motivation
This requirement is intended to ensure that formulae can select facts from the input XRL instance as inputs based upon information in the units of those facts.
e.g.: A formula to convert balances in USD to balances in GBP would need to check that the input facts are expressed in USD.
2.9.3	Variable bindings to facts MAY filter based upon their decimals or precision values
2.9.3.1	Mailing list thread: http://tinyurl.com/36652q
2.9.3.2	Motivation
This requirement is included for completeness, giving coverage of all information that comes with a numeric fact in an XBRL instance.
2.9.4	Variable bindings to facts MAY filter based upon their surrounding tuple structure
2.9.4.1	Mailing list thread: http://tinyurl.com/36652q
2.9.4.2	Motivation
This requirement is intended to ensure that formulae can select facts from the input XRL instance as inputs based upon the contextual facts included in the tuple or tuples that contain it.  This includes the name of the containing tuple/s as well as the information available for other items that are also contained by those tuples.
e.g.: A formula computes total remuneration for an executive based upon remuneration facts reported in tuples where the tuples have to be matched based upon the name of the individual who received the remuneration (reported as sibling facts within the tuples).
2.9.5	Variable bindings to facts MAY filter based upon information in the DTS
2.9.5.1	Mailing list thread: http://tinyurl.com/36652q
2.9.5.2	Motivation
This requirement is intended to facilitate fact selection for input into a formula based upon DTS information such as XDT dimensions, or participation of the fact's concept in specified networks of relationships.
e.g.: A formula specifies how values are to be added up across a dimension breakdown to get the total across that dimension.
e.g.: A formula is only to be used with input facts with concepts that are included in a specific presentation network.
2.9.6	In evaluating a formula, the binding for one variable MAY condition on the bindings for others
2.9.6.1	Mailing list thread: http://tinyurl.com/36652q
2.9.6.2	Motivation
e.g.: Movement analysis where fact selection involves cross-period restrictions.
2.9.7	Variables MUST only bind to facts that are explicitly present in the input
2.9.7.1	Mailing list thread: http://tinyurl.com/36652q
2.9.7.2	Motivation
This requirement is included to ensure that the universe of facts available for binding to is consistent across processors.
2.9.8	Variables MAY filter input facts based on the filters applied by other variables
2.9.8.1	Mailing list thread: http://tinyurl.com/36652q
2.9.8.2	Motivation
This requirement is a consequence of the no-redundancy requirement 2.5.1.
2.9.9	The variables in a formula MAY bind to processor inputs in multiple ways, with each binding resulting in a separate formula evaluation
2.9.9.1	Mailing list thread: http://tinyurl.com/36652q
2.9.9.2	Motivation
This requirement is intended to facilitate evaluation of a formula against an input XBRL instance for all configurations of the data in that instance that match the binding conditions in the formula.
e.g.: A formula can be used to derive earnings per share from earnings and share data.  It can, thus, be used to generate the earnings per share fact for the current and the previous period in an XBRL instance that reports a complete financial statement.  This involves two different binding configurations.
2.9.10	Binding rules MUST cover the handling of duplicate facts in an XBRL instance in a manner that is consistent with the XBRL 2.1 specification
2.9.10.1	Mailing list thread: http://tinyurl.com/2v6hz6
2.9.10.2	Motivation
This requirement has been included to ensure that the treatment of duplicates in the formula specification does not lead to inconsistent interpretations to those specified in the XBRL 2.1 specification.
2.9.11	Variables MUST bind to facts, not to their values
2.9.11.1	Mailing list thread: http://tinyurl.com/2v4nc8
2.9.11.2	Motivation
The motivation for this requirement is that it is a logical consequence of other requirements relating to what bindings can condition on (context, units, etc.).
2.9.12	Variables MUST be able to bind to sequences of facts
2.9.12.1	Mailing list thread: http://tinyurl.com/2ry5dx
2.9.12.2	Motivation
This requirement is included to enable formula to expression operations involving aggregation across sequences of facts.
e.g.: Construction of an average of a set of fact values.
A.	
References (non-normative)
[CRFR]	Walter Hamscher, Geoff Shuetrim, David vun Kannon
XBRL Formula Requirements, Candidate Recommendation, 2005-05-21
http://www.xbrl.org/SpecRequirements/ 
	
[DIM]	Ignacio Hernández-Ros, Hugh Wallis.
XBRL Dimensions 1.0 Recommendation, 2006-09-18.
http://www.xbrl.org/SpecRecommendations/	
[TCR]	Gianluca Garbellotto, Geoff Shuetrim
Tuple Creation Requirements
	
[XIVR]	Victor Morilla, Geoff Shuetrim.
XBRL Instance Validation Requirements
http://tinyurl.com/34npwh
	
[RFC2119]	Scott Bradner
Key words for use in RFCs to Indicate Requirement Levels, March 1997
http://www.ietf.org/rfc/rfc2119.txt
	
[XBRL]	Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis.
Extensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2006-12-18.
http://www.xbrl.org/SpecRecommendations/	
B.	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).
C.	Acknowledgements (non-normative)
This document is a result of careful consideration by the participants of the XBRL International Formula Working Group.  The XBRL International Formula Working Group is chaired by Geoff Shuetrim (Galexy) and vice chaired by Herman Fischer (UBMatrix).
D.	Approval process (non-normative)
This section will be removed from the final recommendation.
This specification is being developed following the XBRL Technical Working Group Processes: http://www.xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-17.htm
E.	Document history (non-normative)
Date	Editor	Remarks	
2002-01-10	vun Kannon	Note posted on XBRL-SpecV2 group describes the design of the “Computational Linkbases” prototype by David vun Kannon and Yufei Wang of KPMG.	
2002-01-25	Hamscher	First draft of “Augmented Computational Linkbases” which included both requirements and an alternate design proposal.	
2002-02-18	Hamscher	Edits after draft reviewed by David vun Kannon.	
2002-02-20	Hamscher	Draft distributed to the XBRL-SpecV2 group.	
2002-02-27	Hamscher	Draft with inline edits by Geoff Shuetrim published to XBRL-SpecV2 group.	
2002-07-01	Hamscher	Reissued as internal working draft of a Requirements document, with examples from Rene van Egmond added.  The notion of a “rule base” is the functional requirement which might be satisfied by a computational linkbase with modifications.	
2002-07-03	Hamscher	Issued as internal working draft to XBRL-SpecV2 group after comments by contributors.	
2002-08-31	Hamscher	Incorporated comments on initial working draft.  In recognition of issues illustrated in the draft specification of 2002-08-19, some requirements were reworded, dropped, or changed category.	
2002-09-10	Hamscher	Incorporated further minor comments and requested issuance as a public working draft.	
2002-09-25	Hamscher	Relaxed the requirement for an open source implementation, and relaxed the requirement with respect to XPATH 2.0.  Changed intellectual property notices to conform to IPR policy currently pending ISC approval.  Revised target approval dates.  Requested again issuance as a public draft.	
2002-09-26	Hamscher	Corrections in use cases and various typos caught by Watanabe-san.  Added line numbering to facilitate commentary.	
2002-10-01	Hamscher	Finalisation for public release.  Removed redundant use case 5 and renumbered the remainder.	
2002-10-16	Hamscher	Various errata from Hugh Wallis.  Returned to previous numbering and stabilised on UC01, UC02, etc.  Reinstated a simplified UC05.	
2002-10-22	Hamscher	Various marginal notes included from New York face-to-face meeting 22 October 2002 which changed the status of some requirements from basic to complex and vice versa.	
2003-11-14	Hamscher	Updated entire document contents to conform to XBRL 2.1 syntax and style.  Defined the relationship between this new specification and XBRL 2.1.  Removed the distinction between basic and complex requirements.  Restated each requirement as a normative statement and defined conformance with stringency similar to that of XBRL 2.1.  Included consideration of the impact of duplicates and other XBRL 2.1 issues.  Eliminated the Open Issues and Design notes sections, folding any relevant remarks into the explanation for each requirement.  Revised use cases to remove cases now irrelevant and added general scenarios of use.	
2003-12-07	Hamscher	Incorporated feedback from Yuji Furusho, Geoff Shuetrim and others.	
2004-01-08	Hamscher	Reworked the use cases to use a common set of concepts, contexts, and units.  Reorganised document to emphasise concrete use cases.  Broke requirements up into several separate sections by theme.  Distributed a truncated draft for comments to the Formula subgroup.	
2004-01-12	Hamscher	Brought draft into alignment with issues list.  Referenced each individual requirement to a use case.   Added additional use cases but left others open for others to add.  Added sections of proposed and rejected requirements (and use cases).  Indicated in the draft where outstanding decisions need to be made and provided notes on the issues.	
2004-01-18	Hamscher	Promoted the proposed requirements for multiple formulas per item, and globally defined functions; added several new proposed requirements that emerged in online discussions.  Added an approval requirement that terms must not be redefined.  Added explicit requirement that expressions may produce tuples.  Made editorial change to distinguish arguments and variables.  Added use cases to clarify the treatment of units in output expressions.  Updated target completion dates.	
2004-02-02	Hamscher	Added explanation of general use cases and added proposed requirement relaxing the need for XBRL output.	
2004-02-11	Hamscher	Rejected the requirement that each formula binds a fixed number of facts, replacing it with a use case involving summation across segments and the accompanying requirement that expressions must be able to access the DTS of the instance that it is processing.  Merged David vun Kannon’s edits to expression syntax so as to use XPATH 2.0 W3C Working Draft 12 November 2003 syntax, and incorporated his observations into a table in the “broadly implemented expression language” requirement. Promoted the rejected requirement to have computed item results to a proposed requirement.	
2004-02-16	Hamscher	Merged comments from Hugh Wallis to use s‑equal instead of “equivalent” or “same” contexts, and typographical errors in some use cases.  Reworded the use case for formula prohibition to refer to sets of formulas rather than taxonomies.  Moved “arbitrary XML output” from proposed to rejected.  Added result requirement that formula must indicate whether result is a child of the xbrl element or the last tuple.	
2004-03-17	Hamscher	Incorporated changes to rules so as to align the treatment of formulas from the standpoint of duplicates and archiving with the treatment of calculation arcs under XBRL 2.1.  Edited the rule regarding prohibition.  Corrected typos found by Mark Goodhand.	
2004-04-06	Hamscher	Modified the segment summation use case to clarify that the formula fact matching over segments must take into account the meaning of the segment child elements, and conversely that the segment child elements should be designed so as to distinguish orthogonal segmentations.  Clarified the rule regarding input copying so as to remove it from the realm of linkbase syntax.   Promoted the requirement for accessibility of all parts of the input instance to a full requirement.  Removed use case involving formula sequencing using roles.  Rejected requirements concerning processing iterations, multiple alternative item outputs, computation of output units, and testing for duplicate outputs.  Clarified that the output instance may have duplicate contexts and units, so long as the result is XBRL-valid.	
2004-04-20	Hamscher	Edit to turn Internal WD into Public WD, no other changes.	
2005-06-07	Hamscher	Reorganized individual use cases into examples to support requirements; layered the requirements into four generic use cases, and relaxed the requirement that the specification satisfy all requirements of all use cases.  Updated reference list.  Edit to turn PWD into Draft Candidate Recommendation.	
2005-06-13	Hamscher	Typographical corrections.	
2007-01-23	Geoff Shuetrim	First draft of version reviewed by the newly constituted Formula Working Group.  Use case and explanatory materials remain to be incorporated from the previous version.	
2007-02-01	Hugh Wallis	Editorial to reflect Public Working Draft status	
2007-03-21	Geoff Shuetrim	Added in mailing list thread references and textual explanations of motivations for the requirements along with examples, many of which were based on simplifications of the detailed use cases included in the previous requirements document.
A number of outstanding issues and questions about the requirements were also identified and documented.