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.
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:
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.
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:
if the maturity level of the transformation rules registry is
REC, the value shall beREC, indicating Recommendation;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;otherwise, the value shall be one of:
IWD, indicating Internal working draft;DPWD, indicating Draft public working draft;PWD, indicating Public working draft; orCR, indicating Candidate recommendation; but the valueCRshall 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.
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.