1 Motivation (non-normative)

The XBRL 2.1 specification [XBRL] describes several equality predicates (section 4.10 Equality predicates relevant to detecting duplicate items and tuples). These predicates are essentially comparative operators that operate on two arguments and return a true or false value. They are defined in the XBRL 2.1 core specification [XBRL] to aid in the understanding of duplicate items and tuples, but the predicates are used throughout the specification aid in the understanding of XBRL.

These predicates can useful beyond as language of the specification. Often in XBRL processing it is necessary for a processor to implement these predicates as functions in a programming language.

XBRL processing, and in particular the processing required to implement Formula Linkbase functionality, relies on a number of common operations. For example, finding the endpoint of the period of a fact relies on common functionality that would typically be implemented as a set of functions. Traditionally, these implementations have been proprietary. However, there is a growing need to standardize the signatures (input/outputs) of these functions to support future XBRL specifications.

1.1 Scope

The functions are required only to aid processing of XBRL facts and contexts appearing in XBRL instances. Processing of XBRL linkbases inside of instances (e.g., footnotes) or outside of them (e.g., labels) is out of scope in this version.

1.2 Terminology and formatting conventions

Terminology used in XBRL frequently overlaps with terminology from other fields. The terminology used in this document is summarised in Table 1.

Table 1. Terminology

abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor.	As defined in [XBRL].
must, must not, required, shall, shall not, should, should not, may, optional	See [RFC2119] for definitions of these and other terms. These include, in particular: should Conforming documents and applications are encouraged to behave as described. must Conforming documents and consuming applications are required to behave as described; otherwise they are in error.
Binding language	An implementation of the functions will be available in a particular programming language. This is the binding language.
Implementation language	The implementation language is the language in which the behaviour of the functions is implemented. This will often be the same as the binding language but this is not necessarily the case. Notably, XPath 2 functions are typically implemented in another language.

Non-normative editorial comments are denoted as follows and removed from final recommendations:

PE: 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.

1.3 Normative status

This document is normative in the sense that any function specification recommendations by XBRL International must satisfy the requirements as they are stated here.

This document version depends upon XBRL 2.1 Specification Recommendation [XBRL].

XBRL Specification 2.1 does not depend in any way upon this document.

1.4 Language independence

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

2 Requirements

2.1 The functions MUST NOT be defined in terms of any one implementation language.

The purpose of the function specification is to provide a standard API for XBRL related functions. The specification must not require implementation in any specific implementation language. Also, the specification should make all reasonable efforts to ease the implementation in any language.

This requirement applies not only to the syntax and format of the function signatures but also to the type classification used to describe function arguments and results.

The functions specification must only define the function signatures and related documentation. A function signature identifies the name of the function and describes the inputs and outputs. The functions specification may include additional non-normative suggestions or information.

At a minimum, the functions specification must include XPath 2.0 bindings for each function defined.

2.2 The specification SHOULD use a type classification based on the terms used in the XBRL 2.1 specification [XBRL].

Although the type classification must not be specific to an implementation, it must be based in the terminology of XBRL. Potential types may be “item”, “tuple”, “fact”, “concept”, “context”. For example, a function that returns the precision associated with a numeric item would be declared with an argument of type “fact” and a returning type of “precision”.

2.3 The functions MUST apply to XBRL.

The specification must only define functions that apply to XBRL documents. Some functions may be broader in scope than just XBRL. For example, XBRL processing often requires calculations of dates for processing a movement analyses. Even though date calculations cover a much broader scope than just processing XBRL documents, functions related to date calculations may be included in the specification since they are necessary for processing XBRL documents.

2.4 The functions specified MUST cover the predicates defined in section 4.10 of [XBRL].

The list of functions at a minimum must cover all predicates defined in section 4.10 of the XBRL 2.1 specification [XBRL].

2.5 The list of functions MAY include functions that are not based on the predicates defined in section 4.10 of the XBRL 2.1 specification.

The list of functions may include other functions. For example, there may be a function to identify all the labels associated with an XBRL concept.

2.6 The functions specification MUST include an approval process.

The functions specification must include a section describing the approval process for the functions specification. This approval process must state that there are at a minimum two working independent and interoperable implementations, to be confirmed through the existence of a conformance suite consisting of test cases for all defined functions.

3 Document history (non-normative)

Date	Editor	Remarks
2004-12-31	Phillip Engel	First draft of an internal working draft for the function specification is created`
2005-01-06	Phillip Engel	In response to the formula linkbase conference call on 2004-12-126, included the requirement for XPath 2.0 bindings in 2.1. and added requirement 2.6 about the approval process. Also, corrected typos and grammar as identified by HW and other minor clean up.
2005-04-23	Hamscher	Added a scope section saying this version only covers XBRL instances. Added a definition of how interoperable implementations will be determined. Made other formatting changes and typographical corrections.
2005-06-14	Wallis	Removed unused descriptions of example formats from section 1

4 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).

5 References (non-normative)

[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 and Hugh Wallis
	Extensible Business Reporting Language 2.1 Recommendation (with corrected errata to 2005-04-25)
	http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.rtf

[Processes]	Walter Hamscher
	XBRL International Processes 1.0, 4 April 2002
	http://www.xbrl.org/

Appendix: Approval process (non-normative)

This section will be removed from the final recommendation.

The approval process follows XBRL International process for specifications [Processes].

	Stage (* - Current)	Party responsible for decision	Next step	Revisions needed	Target date for stage completion
1	Internal WD	Spec WG Chair	Recommend for Stage 2	Stay in Stage 1	2005-01-27
2	Internal WD pending publication	ISC	Approve for Stage 3	Return to Stage 1	2005-02-01
3	Public WD under 45 day review	WD Editor(s)	Minor revisions – to Stage 4	Major revisions, Restart Stage 1	2005-04-29
4	Public WD pending publication	Spec WG Chair	Recommend for Stage 5	Restart Stage 3	2005-06-21
5	* Candidate Recommendation	ISC	Approve for Stage 6	Restart Stage 4	2005-07-19
6	Recommendation	Done

The process for approving specifications satisfying this requirements document can proceed concurrently, although no specification can be recommended without conforming to a requirements document that has already been recommended.

Name	Contact	Affiliation
Phillip Engel	phillipengel@kpmg.com	KPMG LLP

Editors

Contributors

Status of this document

Table of contents