Copyright ©2011 XBRL International Inc., All Rights Reserved.
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 email@example.com, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
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.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.2 Public review
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
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.
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
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).
The XII Transformation Rules Registry is the transformation
rules registry which incorporates the identifier
http://www.xbrl.org/inlineXBRL/transformation into its
It is owned and managed by XBRL International Inc. ("XII"), in accordance with this
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.
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.
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
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.
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.
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].
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.
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.
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.
The Requirements for transformation rules in the XII Transformation Rules Registry are:
all transformation rules should be of general benefit or wide application;
all transformation rules should be generic, where appropriate;
a group of transformation rules should be conceptually complete, so that together they provide complete coverage for a specific kind of function;
each transformation rule should be semantically complete and schema valid;
each transformation rule should be accompanied by conformance tests that illustrate its operation and can be used to test a processor; and
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.
The Rule Status of a given transformation rule is
indicated by the value of the
element for that entry in the
The Rule Status is set according to the following rules:
if the maturity level of the transformation rules
REC, the value shall be
if the transformation rule was included in a previous version of the
transformation rules registry, the value shall be
Recommendation, unless that rule is in the process of being corrected by way of
an errata correction;
otherwise, the value shall be one of:
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.
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.
The process starts  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 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  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 . 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  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  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  and the Rule
Status of each rule and the maturity level of the
XII Transformation Rules
Registry are set to
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).
This document could not have been written without the contributions of many people.
|28 June 2010||Diane Mueller||
First draft in Word format.
|25 September 2010||Diane Mueller||
Added comments and TRR Process Diagram for discussion purposes.
|31 October 2010||Diane 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 2010||Philip 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 2010||Philip Allen||
Created first draft in the Spec-for-Specs XML format.
|15 November 2010||Philip 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 2010||Philip Allen||
|09 December 2010||Herm Fischer||
Updated TRR Process Diagram and adapted prior descriptive wording to Section 5.5.
|12 December 2010||Diane Mueller||
Revised submission and review section Section 5.5.
|13 December 2010||Herm Fischer||
RWG conf call wording changes to Section 5.5.
|10 January 2011||Philip Allen||
Brought Section 5.5 into line with the rest of the specification.
Corrections per reviews by JDR and APG.
|17 January 2011||Herm Fischer||
|17 January 2011||Philip Allen||
Updated references to diagram.
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.