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

This version:
	Formula-REQ-PWD-2007-01-23.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].  The document is currently extremely brief, containing only a statement of the requirements, without the motivating use cases.
Future drafts will be accompanied by relevant use cases and, as the formula specification stabilises, complete examples supporting those use cases.
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-01-23
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.	Document History (non-normative)
E.	Errata corrections incorporated in this document
F.	Approval process (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.2	Any document that is conformant with specifications produced by the working group will also be a valid XBRL 2.1 document
2.1.3	Any valid XBRL 2.1 document will also be conformant with specifications produced by the working group
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.2	Formulae MUST be able to test for the presence or absence of various properties of the target instance
2.2.3	An XBRL formula processor MUST not generate any other type of XML documents
2.2.4	The output of formula processing MUST include 0, 1 or more XBRL instances
2.2.5	Formulae MAY define functional relationships where facts for the same concept are used both as inputs and as outputs
2.2.6	Formulae MAY define functional relationships that, when evaluated, draw on values for facts that have different contexts and units
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.8	XBRL facts resulting from formula evaluation MAY have contexts and units that are not part of the target instance
2.2.9	Formulae MUST be able to produce any valid value for any XBRL fact
2.2.10	Formulae MUST be able to include preconditions that determine whether the formula itself is to be evaluated
2.2.11	Formula evaluation preconditions MUST not condition on the content of the output XBRL instance
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.3	Formulae and the DTS
2.3.1	A DTS MUST be able to include formulae
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.3	Formulae, constant declarations, and function declarations MAY be partitioned into sets
2.3.4	Formulae in a DTS MUST be able to be prohibited
2.4	Formula documentation
2.4.1	Formulae in a DTS MUST be able to be documented using labels
2.4.2	Formulae MUST be able to have multiple labels, with different purposes and in different languages
2.4.3	Formulae MUST be able to be documented using references
2.5	Formula syntax
2.5.1	The syntax for formulae SHOULD NOT require redundancy
2.5.2	It MUST be possible to define constants outside of a specific formula
2.5.3	It MUST be possible to define constants with values that are built-in XML Schema data types
2.6	Formula processing
2.6.1	Formula processing MUST NOT take a Post Taxonomy Validation Infoset as an input
2.6.2	The result of applying formulas to an instance that is not XBRL-valid is not defined
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.4	Formula processor behaviour MUST be defined in the event of expression evaluation exceptions
2.7	Formula expressions
2.7.1	The expression language MUST include operators to select nodes in the target instance
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.3	The expression language MUST be able to include variables that have values determined outside of the expression itself
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;
●	The range of string matching and modification operations made possible by regular expressions;
●	All of the following relational operations, =, <, >, <=, >=, and != on numeric items and =, != on non-numeric items
Motivating examples:
0001 (illustrates usage of the +, - and = operators).
2.7.5	The expression language MUST support absolute value operations
2.7.6	The expression language MUST support regular expressions
2.7.7	The expression language MUST support standard logical operators
2.7.8	The expression language MUST support if/then/else expressions
2.7.9	The expression language MUST support determination of the maximum and minimum dates in context periods in the target instance
2.7.10	The expression language MUST support testing for the presence or absence of any fact in the target instance
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
2.9	Variable binding
2.9.1	Variable bindings to facts MAY filter based upon their contexts
2.9.2	Variable bindings to facts MAY filter based upon their units
2.9.3	Variable bindings to facts MAY filter based upon their decimals or precision values
2.9.4	Variable bindings to facts MAY filter based upon their surrounding tuple structure
2.9.5	Variable bindings to facts MAY filter based upon information in the DTS
2.9.6	In evaluating a formula, the binding for one variable MAY condition on the bindings for others
2.9.7	Variables MUST only bind to facts that are explicitly present in the input
2.9.8	Variables MAY filter input facts based on the filters applied by other variables
2.9.9	The variables in a formula MAY bind to facts in multiple input XBRL instances if those instances are part of a larger XML document
2.9.10	The variables in a formula MAY bind to processor inputs in multiple ways, with each binding resulting in a separate formula evaluation
2.9.11	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
Pending confirmation that the issues raised by IHR have been addressed.
2.9.12	Variables MUST bind to facts, not to their values
2.9.13	Variables MUST be able to bind to sequences of facts

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/	
[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.	Document History (non-normative)
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