Function Registry Process Documentation
Public Working Draft of 2007-08-03
Copyright © 2004-2007, XBRL International Inc., All Rights Reserved

Editors
Name	Contact	Affiliation	
Hugh Wallis	hughwallis@xbrl.org	XBRL International Inc.	
Geoff Shuetrim	geoff@galexy.net	Galexy Pty. Limited	
Contributors
Name	Contact	Affiliation	

Abstract
This document describes the XBRL International process by which a registry for XBRL functions is updated.  The function registry is an online listing of XBRL functions, along with structured information about their purpose, usage, and their associated conformance tests.
Status
The circulation of this process document is unrestricted  Recipients are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
Editors
Contributors
Abstract
Status
Table of Contents
Table of Figures
1	Goals
1.1	Intended audience
1.2	Document scope
1.3	Organisation of this document
1.4	Terminology and document conventions
1.5	Language independence
2	Update Process
3	Criteria
4	Normative Status of Functions in the FR
A	References (non-normative)
E	Intellectual Property Status (non-normative)
F	Acknowledgements (non-normative)
G	Document History (non-normative)

Table of Figures
Figure 1.  Terminology
Figure 2.  Approval process for FR entries

1	Goals
The goal of the Function Registry (FR) is to be a public, online data set that documents functions intended to operate on information expressed using XBRL.  Additions and other changes to the FR, like other XBRL International work products, will proceed through a series of steps whose goal is to maximise the utility of the functions included in the registry.
1.1	Intended audience
This document is intended for those with an interest in contributing new functions to the FR.
1.2	Document scope
The scope of this document encompasses the processes by which changes are made to the FR.
1.3	Organisation of this document
This document consists of the following sections in addition to this introduction:
•	Process model for changes to the FR;
•	Normative status of functions included in the online resource and its effect on software.
1.4	Terminology and document conventions
Terminology used in XBRL frequently overlaps with terminology from other fields.
Figure 1.  Terminology
		
must, must not, required, shall, shall not, should, should not, may, optional	See http://www.ietf.org/rfc/rfc2119.txt 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.	

CR	Candidate Recommendation	
DCR	Draft Candidate Recommendation	
FR	Function Registry	
FRAG	Function Approval Group	
ISC	International Steering Committee	
FWG	Formula Working Group	
IWD	Internal Working Draft	
PWD	Public Working Draft	
XBRL	XBRL 2.1 recommendation [XBRL].	
XSB	XBRL International Standards Board	

Italics are used for rhetorical emphasis only and do not convey any special normative meaning.
1.5	Language independence
All documentation supporting a function MUST be provided in English, and MAY be provided in additional languages.  The official language of XBRL International is UK English.
2	Update Process
The process by which a function is added to the FR is depicted in Figure 2 below. This is modelled on the standard processes by which XBRL International Working Group work product becomes a RECOMMENDATION.  The steps that a successful entry in the FR will proceed through as set out below:
1.	The submitter of a new function creates an IWD containing all of the information needed and requests the Function Registry Approval Group (FRAG) to enter it into the FR.
2.	The FRAG MAY suggest modifications to the proposal and request the submitters to resubmit the proposal after making those modifications. In the event that there is more than one submission made for similar requirements the FRAG may request the submitters to agree a common solution between themselves and resubmit a single joint IWD. If this is not acceptable to the submitters the ISC will be requested to arbitrate.
3.	The FRAG approves the requirements.  They then conduct a technical evaluation of the proposal. If they determine that wider technical evaluation is necessary they then submit the IWD to the FWG for additional technical evaluation.
4.	If requested in step 3 the FWG deliberates the IWD.
5.	If requested in step 3 the FWG recommends to the FRAG that they approve release of the IWD as a PWD.
6.	The FRAG approves the IWD and recommends to the XSB that it be released as a PWD.
7.	The XSB approves publication as a PWD
8.	The FRAG calls for two implementations of the function if they do not already exist.
9.	The FRAG enters the new function into the FR with its status set to PWD.  A notice of its addition is made to the XBRL-INT and XBRL-Public mailing lists and feedback is requested.
10.	A minimum of forty-five days of public review follow.
11.	The FRAG or, if it decides to delegate this step, the FWG verifies that the conformance suite tests are valid and that there are two separate implementations that pass them.
12.	The FRAG or, if it decides to delegate this step, the FWG makes any necessary amendments pursuant to the PWD feedback and, unless it determines that a new PWD is necessary, the FRAG recommends to the XSB that a DCR be published (amended if appropriate) as a CR.
13.	The XSB approves the CR.
14.	Two weeks pass during which only minor editorial changes MAY be made.  Such changes MUST be approved by the FRAG.  Substantive changes require a new DCR (return to step 12).  The FRAG recommends to the XSB that it be published as a recommendation who in turn recommend such to the ISC.
15.	The ISC approves the recommendation.
The process by which an function may be updated in the FR is analogous.   If errata are discovered in any function then a new version of the function will be entered into the FR following the same process as that used for errata corrections to the specification itself. The effective date of the errata corrected version will be later than that of the original and will thus supersede it.  Superseded functions will be identified as deprecated in the FR.
3	Criteria
A function must meet these criteria to be approved by the FRAG:
•	Semantically distinct from existing functions;
•	Of sufficient generality to be of broad use; 
•	Sufficiently well documented to encourage correct usage.
4	Normative Status of Functions in the FR
Once a function has the status of REC in the FR it shall have the same normative status as any specification recommended by XBRL International.
It is expected that software vendors will make claims regarding which additional functions they support. They must point to successful exercising of the relevant conformance suite tests in order to substantiate such claims.
Figure 2.  Approval process for FR entries

Yes

Editor

Specification WG

XSB

ISC

1. Submit

proposal

Is its utility

in doubt?

Is it useful

and distinct?

Yes

No

4. Review

Drafts

2. Suggest

Alternatives

ISC must arbitrate

when multiple

submitters

cannot agree.

Substantive

revisions

needed

Submit

Revised

Internal

Working Draft

8. Recommend as

PWD

9. Approve

as PWD

5. Call for 2

Implementations

10. Enter into FR

with status PWD

and notify via

XBRL-Public and

XBRL-INT

7. Approve

as PWD

13.  Amend and

Approve as DCR

14. Approve

as CR (or

delegate

authority)

Substantive

revisions

needed

6. Recommend

to FRAG as PWD

Needs

Revisions

Editorial

revisions

needed

16. Approve

as REC

(or delegate

authority)

FRAG

3. Approve

Reqs.

No

15. Two weeks of

public review;

editorial changes

only

11. 45 days or more

of public review

12. Verify

conformance and

implementation

Substantive

revisions

needed

1	
A	References (non-normative)
The hyperlinks to HTML format XBRL International documents are to the non-normative versions of those documents but are provided in this format for convenience. Those documents indicate the location of their relevant normative versions.
[ISO]	International Standards Organisation.	
	ISO 4217 Currency codes, ISO 639 Language codes, ISO 3166 Country codes, ISO 8601 international standard numeric date and time representations.	
	http://www.iso.ch/	
		
[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 2003-12-31 + Corrected Errata - 2005-11-07	
	http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-11-07.htm	
E	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).
F	Acknowledgements (non-normative)
The participants in the XBRL Formula Working Group and public commentators have all played a role.
G	Document History (non-normative)
Date	Editor	Summary	
2007-07-25	Geoff Shuetrim	First draft of document prepared.	
2007-08-01	Geoff Shuetrim	Comments from Roland Hommes and Hugh Wallis incorporated into the document.	
2007-08-03	Geoff Shuetrim	Changed the choice of acronym.  Eliminated remaining reference to LRR.	
2007-08-03	Hugh Wallis	Corrected some spelling mistakes, headers and footers, copyright notices and updated flow chart