Transformation Rules Registry - Process 1.0

Public Working Draft 17 January 2011

Copyright ©2011 XBRL International Inc., All Rights Reserved.

This version:
<http://www.xbrl.org/Specification/TRR-process/PWD-2011-01-17/TRR-process-PWD-2011-01-17.html>
Editors:
Philip Allen, CoreFiling Limited <plega@corefiling.com>
Diane Mueller, XBRLSpy Research Inc. <dmueller2001@GMAIL.COM>
Hugh Wallis, XBRL International <hughwallis@xbrl.org>
Herm Fischer, Mark V Systems <fischer@markv.com>

Status

Circulation of this Public Working Draft is unrestricted. This document is normative. Other documents may supersede this document. Recipients are invited to submit comments to rendering-feedback@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Abstract

This document provides a description of the purpose and operation of transformation rules registries in support of the [Inline XBRL Specification]. It defines the specific process by which the XII Transformation Rules Registry may be changed and re-issued.

Table of Contents

1 About this document
1.1 Conventions used in this document
1.2 Namespace prefixes
2 Introduction (non-normative)
3 The XII Transformation Rules Registry
4 Transformation rules registries (non-normative)
4.1 Content
4.2 Amendments to a registry
4.3 Identification of registries and versions
4.4 Purpose of registry versioning
4.5 The Specified Registry
4.6 Processor support for registries
5 Update Process
5.1 Authority
5.2 Public review
5.3 Requirements
5.4 Maturity level and status
5.4.1 Transformation rules
5.4.2 Transformation rules registries
5.5 Submission and review process
6 Conformance suite

Appendices

A References
B Intellectual property status (non-normative)
C Acknowledgements (non-normative)
D Document history (non-normative)
E Errata corrections in this document

Figure

1 Submission and review process (non-normative)

Definitions

RWG
Requirements
Rule Status
XBRL International Inc.
XII Transformation Rules Registry
XSB


1 About this document

1.1 Conventions used in this document

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [IETF RFC 2119].

The key words Inline XBRL document, specified registry, transformation rule and transformation rules registry in this document are to be interpreted as described in the [Inline XBRL Specification].

The key words errata corrections and maturity level in this document are to be interpreted as described in [TECH-WG-PROCESSES].

The key words element, type and valid in this document are to be interpreted as described in the [XML] specification.

The key words local name, namespace, namespace name and namespace prefix in this document are to be interpreted as described in the [XML Names] specification.

1.2 Namespace prefixes

This document uses the namespace prefix of reg when describing elements with the namespace name of http://xbrl.org/2008/registry.

2 Introduction (non-normative)

This document describes the process used by XII for updating its transformation rules registry. Although the process applies to a special-case registry - the XII registry itself - much of the document also applies to generic transformation rules registries such as might be created by other parties.

The section on transformation rules registries is non-normative because everything in it has already been defined in other specifications, as mentioned in the first paragraph of the section. It applies to general transformation rules registries as well as the one in question.

The most important part of the process document is the list of Requirements. These determine whether or not updates to a registry are acceptable, and define what a user should be able to expect from a registry. Much of the approval process depends upon standards laid down in other relevant specifications. The rules controlling <reg:status> are set out in the [XBRL Registry] specification, so all the present document does is to describe the circumstances under which each value would be appropriate. Likewise, maturity levels have already been defined in [TECH-WG-PROCESSES] so, to avoid confusion, they are not repeated here. Note, however, the distinction between Rule Status (for registry entries) and maturity level (for the complete registry).

3 The XII Transformation Rules Registry

The XII Transformation Rules Registry is the transformation rules registry which incorporates the identifier http://www.xbrl.org/inlineXBRL/transformation into its namespace name. It is owned and managed by XBRL International Inc. ("XII"), in accordance with this specification.

4 Transformation rules registries (non-normative)

4.1 Content

A transformation rules registry is a registry of functions for use in Inline XBRL documents, as defined in [Inline XBRL Specification]. The structure and operation of a transformation rules registry is defined in [XBRL Registry]. The form of each function is defined in [XBRL Function Definitions]

A transformation rules registry consists of transformation functions, each with schema-validatable input and output types. By using these functions, authors of Inline XBRL documents can display data in a format which would not be acceptable if output in an XBRL instance document.

4.2 Amendments to a registry

Changes to a transformation rules registry can only be either errata corrections or new versions of the transformation rules registry. Errata corrections cannot be used to add new functions to the transformation rules registry or to remove existing functions. New versions of the transformation rules registry are copies of previous versions, with the addition of new functions and the removal of functions which are no longer required.

A transformation rule or function is identified by its local name. A given local name can only be used to identify that particular function and cannot be reused for another function in a later version of the transformation rules registry. Neither errata corrections nor new versions of the transformation rules registry can be used to change the functionality of a given transformation rule. It follows that, if a given local name appears in different versions of a transformation rules registry, it will always identify precisely the same function.

4.3 Identification of registries and versions

A transformation rules registry is identified by its namespace name, which is in the form "identifier/date": for example, http://www.registryowner.org/registry/1805-10-21. The date at the end of the namespace name is the date used to identify the version of the transformation rules registry which was accorded Recommendation status.

Note that the publication of errata corrections will not affect the namespace name of the relevant transformation rules registry. It therefore becomes impossible to distinguish between the originally published version of that transformation rules registry and the corrected version, because both have the same namespace. Reference to a given version of a transformation rules registry is consequently always taken to mean a reference to that version as amended by all the subsequent errata corrections to that version, if any.

It also follows that a given transformation rule may be published under a number of different namespaces, each namespace name differing only by the trailing date, but keeping the same local name in each case.

4.4 Purpose of registry versioning

The versioning rules outlined above are designed to make it as simple as possible to specify a given support function set for implementers and users of the [Inline XBRL Specification]. Allowing the removal of functions from subsequent versions of a transformation rules registry (while they persist in the former namespace) is a clean mechanism for handling deprecation without withdrawing support for documents written against a former function set.

Because a given local name always refers to the same transformation rule, whatever the registry version, processors should be able to handle multiple versions of a transformation rules registry without confusion.

4.5 The Specified Registry

The version of the XII Transformation Rules Registry with the namespace name which has the value http://www.xbrl.org/inlineXBRL/transformation/2010-04-20 is called the specified registry. Subsequent versions of this registry are not specified and have no special standing in the [Inline XBRL Specification].

4.6 Processor support for registries

Processor support for a transformation rules registry means support for a given version of that transformation rules registry and all the errata corrections which apply to it. It does not imply support for other versions of the same transformation rules registry.

Any processor which claims conformance to the [Inline XBRL Specification] must support the specified registry. It does not need to support subsequent versions of that registry.

If a processor supports a given version of a transformation rules registry it must support all the rules in that version, whether or not those rules appear in later versions of that registry. Thus, support for a given version is the same thing as saying that a processor can handle all the functions defined in a particular namespace.

5 Update Process

5.1 Authority

The XII Transformation Rules Registry is published under the authority of XII on the recommendation of the XBRL International Standards Board ("XSB"). The XSB will, from time to time, appoint a delegate to review changes to the transformation rules registry and to report on whether they meet the Requirements. That delegate is currently the Rendering Working Group ("RWG") and references to the RWG herein refer to it in its role as such delegate. Changes to the XII Transformation Rules Registry should be submitted to that delegate.

5.2 Public review

Public review is a necessary part of the approval process. The body reporting that changes to the XII Transformation Rules Registry meet the Requirements MUST request public feedback through suitable channels when it issues the CR draft, and that draft MUST be publicly available for a minimum of 45 days, unless otherwise agreed by the XSB.

5.3 Requirements

The Requirements for transformation rules in the XII Transformation Rules Registry are:

  1. all transformation rules should be of general benefit or wide application;

  2. all transformation rules should be generic, where appropriate;

  3. a group of transformation rules should be conceptually complete, so that together they provide complete coverage for a specific kind of function;

  4. each transformation rule should be semantically complete and schema valid;

  5. each transformation rule should be accompanied by conformance tests that illustrate its operation and can be used to test a processor; and

  6. each transformation rule should be accompanied by one or more reference implementations, according to such requirements as the XSB may lay down from time to time.

Each version of the XII Transformation Rules Registry  MUST meet the Requirements.

5.4 Maturity level and status

5.4.1 Transformation rules

The Rule Status of a given transformation rule is indicated by the value of the <reg:status>  element for that entry in the registry.

The Rule Status is set according to the following rules:

  1. if the maturity level of the transformation rules registry is REC, the value shall be REC, indicating Recommendation;

  2. if the transformation rule was included in a previous version of the transformation rules registry, the value shall be REC, indicating Recommendation, unless that rule is in the process of being corrected by way of an errata correction;

  3. otherwise, the value shall be one of:

    • IWD, indicating Internal working draft;

    • DPWD, indicating Draft public working draft;

    • PWD, indicating Public working draft; or

    • CR, indicating Candidate recommendation; but the value CR shall only be used where the XSB or its delegate has approved the transformation rule as meeting the Requirements.

5.4.2 Transformation rules registries

The maturity level of a given transformation rules registry is set according to the rules defined in sections 7.2.1 (Maturity Level for Work in Progress) and 7.2.2 (Maturity Levels of the Recommendation Path) of [TECH-WG-PROCESSES]. Section 7.2.5 (Maturity Level When Editing a Recommendation) MAY be used only in the case where errata corrections are being applied to an existing published version of a transformation rules registry.

5.5 Submission and review process

The deprecation of transformation rules and the addition of new transformation rules to the XII Transformation Rules Registry SHOULD follow the process described below. Figure Figure 1 is a non-normative diagram of this process.

Figure 1: Submission and review process (non-normative)

The process starts [0] when a proposer requests, with reasons, the deprecation of an existing transformation rule or the addition of a new transformation rule. A request to add a new transformation rule SHOULD be accompanied with samples of input and output of the proposed transformation rule and a definition of the type for the input.

The RWG SHALL [1] assess such proposals against the Requirements and, if it takes the view that they will not be met, MAY refuse the proposal or suggest changes as it sees fit.

The proposer MAY, if he disagrees with the view of the RWG, call [2c] on the XSB to arbitrate. The XSB MAY, if it agrees with the proposer, require [3] the RWG to accept the proposal or suggest changes as it sees fit.

Once the proposal has been accepted, it shall be documented [2b] within the XII Transformation Rules Registry with the appropriate working draft Rule Status, and the addition [2a] of conformance test cases and (if applicable) reference implementation.

The RWG having established that the proposal meets the Requirements, the proposal is made available for public evaluation [4]. Members of the public SHOULD be invited to comment on the proposal and to give reasons why it should or should not be accepted. If the RWG takes the view that, as a result of these comments, the Requirements will not be met, it MAY refuse the proposal or suggest changes as it sees fit.

Subject to satisfactory public review of any and all proposals, the RWG recommends [5] to the XSB that the XII Transformation Rules Registry be published as a Recommendation. The XSB will authorise such publication in accordance with and subject to its own processes. At the time of writing, those processes include requesting authorisation [6] for such publication from the International Steering Committee of XII.

Following the authorisation of the XSB the namespace name of the XII Transformation Rules Registry is updated [8] and the Rule Status of each rule and the maturity level of the XII Transformation Rules Registry are set to REC.

6 Conformance suite

Processors which claim support for a given version of the XII Transformation Rules Registry MUST point to successful exercise of the conformance suite tests relating to that version of the XII Transformation Rules Registry in order to substantiate such claim.

Appendix A References

IETF RFC 2119
IETF (Internet Engineering Task Force). "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
Scott Bradner.
(See http://www.ietf.org/rfc/rfc2119.txt)
Inline XBRL Specification
XBRL International Inc.. "Inline XBRL Part 1: Specification 1.0"
Philip Allen, and Ian Stokes-Rees.
(See http://www.xbrl.org/Specification/inlineXBRL-part1/REC-2010-04-20/inlineXBRL-part1-REC-2010-04-20.html)
TECH-WG-PROCESSES
XBRL International Inc. "XBRL International Technical Working Group and Work Product Process"
XBRL International Standards Board.
(See http://www.xbrl.org/XSB/XBRL_Technical_Working_Group_Processes-Approved-2007-04-17.htm)
XBRL Function Definitions
XBRL International Inc.. "Function definition 1.0"
Geoff Shuetrim.
(See http://www.xbrl.org/Specification/functionDefinition/REC-2009-06-22/functionDefinition-REC-2009-06-22.html)
XBRL Registry
XBRL International Inc.. "XBRL Registry Specification 1.0"
Geoff Shuetrim.
(See http://www.xbrl.org/Specification/registry/REC-2009-06-22/registry-REC-2009-06-22.html)
XML
W3C (World Wide Web Consortium). "Extensible Markup Language (XML) 1.0 (Fifth Edition)"
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau.
(See http://www.w3.org/TR/REC-xml/)
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/)

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

Appendix C Acknowledgements (non-normative)

This document could not have been written without the contributions of many people.

Appendix D Document history (non-normative)

DateAuthorDetails
28 June 2010Diane Mueller

First draft in Word format.

25 September 2010Diane Mueller

Added comments and TRR Process Diagram for discussion purposes.

31 October 2010Diane Mueller

Updated TRR Process Diagram. Removed references to Aknowledgement Status; removed requirement for 2 implementations; added in RWG responsible for updating reference implementation & conformance suite tests

05 November 2010Philip Allen

Added non-normative descriptions of versioning structure; updated process to bring it into line with iXBRL specification; simplified definition of the parties involved; suggested resolution to "rescinding" wording.

12 November 2010Philip Allen

Created first draft in the Spec-for-Specs XML format.

15 November 2010Philip Allen

Removed statement regarding XII policy, which might change in future.

Removed reference to ISC.

Moved comments into an Introduction section.

Add requirement for semantic completeness and schema-validity.

06 December 2010Philip Allen

Fixed typo.

09 December 2010Herm Fischer

Updated TRR Process Diagram and adapted prior descriptive wording to Section 5.5.

12 December 2010Diane Mueller

Revised submission and review section Section 5.5.

13 December 2010Herm Fischer

RWG conf call wording changes to Section 5.5.

10 January 2011Philip Allen

Brought Section 5.5 into line with the rest of the specification.

Corrections per reviews by JDR and APG.

17 January 2011Herm Fischer

Updated diagram.

17 January 2011Philip Allen

Updated references to diagram.

Appendix E 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 Rendering Working Group up to and including 17 January 2011. 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.