Copyright © 2011, 2012, 2013 XBRL International Inc., All Rights Reserved.
Circulation of this Recommendation is unrestricted. This document is normative. Recipients are invited to submit comments to utram@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.
This document describes the structure of the XBRL International Units Registry. The Units Registry is an online listing of units that have been identified as potentially having wide utility. The Registry contains structured information about their purpose, usage and any intended impact on XBRL instance validation.
1 Goals
1.1 Relationship to other work
1.2 Terminology
1.3 Language
1.4 Document conventions
1.4.1 Typographic conventions
1.4.1.1 Definition notation
1.4.1.2 Footnote notation
1.4.1.3 Element and attribute notation
1.4.2 Formatting conventions
1.5 Namespaces and namespace prefixes
2 Data Model
3 Hosting on the XBRL.org website
4 Validation
5 Status of Units in the UTR and Implications for Software
A Schema
A.1 utr.xsd
B Sample utr document (non-normative)
C References
D Intellectual property status (non-normative)
E Acknowledgements (non-normative)
F Document history (non-normative)
G Errata corrections in this document
1 Namespaces and namespace prefixes
2 A UTR entry
CR
Complex unit definition
Division-to-type match
Has a fact-to-UTR-match
Has a type
IWD
Measure match
Measure-to-type match
Most specific ancestor in the UTR
Most specific type present in the UTR
PWD
Present in the UTR
Present in the UTR
Simple unit definition
Type match
UTR
UTR-valid
abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, 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
instance-utr-valid
unit-to-type match
XBRL provides a set of standard units that may appear in XBRL instances. These include those specified in [XBRL 2.1]. As XBRL applications have emerged, unit declarations have appeared in XBRL instance documents having multiple names for equivalent meanings, and identical names having different meanings. The goal of the XBRL Units Registry (hereinafter "UTR") is to be a public, online data set that documents these units and their usage and allows a processor to determine whether the numeric facts in an XBRL instance use appropriate units. Additions and other changes to the UTR, like other XBRL International work products, will proceed through a series of steps whose goal is to maximise the utility and longevity of the new units and the instances that use them. This process is documented in [UTR PROCESS].
This document pertains to XBRL as defined in the XBRL Specification [XBRL 2.1].
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in [IETF RFC 2119].
abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, 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 and any other terms not specifically defined elsewhere in this document but which are used and defined in the XBRL 2.1 specification are as defined by [XBRL 2.1] .
CR refers to a Candidate Recommendation of XBRL International.
IWD refers to an Internal Working Draft of XBRL International.
UTR refers to the Units Registry that is the subject of this specification.
The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.
All documentation supporting a registry entry MUST be provided in English, and MAY be provided in additional languages.
Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.
When referring to a specific element, it will be identified by
its namespace prefix and local name. For example, the root element
of a versioning report would be referred to as <ver:report> .
Attributes are also identified by their local name and, where
appropriate, their namespace prefix. Attributes are
distinguished from elements by prefixing them by an
@
symbol. Thus,
@id
refers to the attribute with the name id.
When referring to any attribute, so long as it has a specific
namespace, the local name is replaced by an asterisk (
*).
Thus, the notation @xml:* specifies any attribute
in the namespace
http://www.w3.org/XML/1998/namespace.
The following highlighting is used for normative technical material in this document:
Text of the normative example.
The following highlighting is used for non-normative examples in this document:
Text of the non-normative example.
The following highlighting is used for non-normative examples of poor, discouraged or disallowed usage.
Text of the discouraged example.
Namespace prefixes [XML Names] will be used for elements and
attributes in the form <ns:name> where ns is the namespace prefix and name is the
local name. Throughout this specification, the mappings from namespace prefixes to actual namespaces is consistent
with Table 1.
The prefix column in Table 1 is non-normative. The namespace URI column is normative.
| Prefix | Namespace URI |
|---|---|
| iso4217 | http://www.xbrl.org/2003/iso4217 |
| utr | http://www.xbrl.org/2009/utr |
| utre | http://www.xbrl.org/2009/utr/errors |
| xbrli | http://www.xbrl.org/2003/instance |
The data model of the UTR is a list of each unit definition augmented with additional indicators and information needed by developers and used by a processor to determine whether an XBRL instance is UTR-valid. A unit definition can be either simple or complex.
A simple unit definition defines a unit with a single measure.
A complex unit definition defines a set of units that have a numerator and a denominator that are each simple unit definitions.
For example, a unit representing a currency would be a defined by a simple unit definition, whereas a unit definition representing a monetary value per share would be a complex unit definition.
The UTR cannot contain a product of measures; nevertheless, a fact with a unit having a product of measures or a product of measures in its numerator or denominator, can still be UTR-valid provided that the fact does not have a type that is present in the UTR.
If <xbrli:decimalItemType> is not present in the UTR then facts of that type MAY have any
XBRL 2.1 valid unit.
| Field | Min | Max | Type | Explanation | Element or Attribute | Example(s) |
|---|---|---|---|---|---|---|
| ID | 1 | 1 | ID | The ID attribute of this entry, unique within the scope of the Units Registry. | @id |
u00256 |
| Unit ID | 1 | 1 | NCName |
When combined with the Unit Namespace (if present), this provides a unique identifier for the entry. The Unit ID alone need not be unique in the scope of the UTR because there could be (for example) a REC definition of a unit, and an IWD version of it. In the case of a simple unit definition, the Unit ID is the QName content of the measure element of occurrences of the unit. |
<unitId> |
GBP sqft MMBbls Monetary_per_Share |
| Unit Name | 1 | 1 | string | The name of the unit being defined, which MAY have spaces and other characters and is conventionally in Proper Case. | <unitName> |
Square Foot Thousands of Barrels of Oil |
| Unit Namespace | 0 | 1 | URI |
When present, the namespace in which the unit is declared in a
The combination of Unit ID and Status MUST be unique within the scope of the registry. |
<nsUnit> |
http://www.xbrl.org/2009/utr |
| Item Type | 0 | 1 | NCName | The local-name of a type that this unit is a type match for. .
|
<itemType> |
areaItemType |
| Item Type Namespace | 0 | 1 | URI |
If the namespace of Item Type is limited, then it is provided here. If present, then Item Type MUST be present in this unit definition. |
<nsItemType> |
http://www.xbrl.org/dtr/type/numeric |
| Item Type Date | 0 | 1 | date | Version date of the XBRL specification or data type registry in which the item type first appears, or empty if the type is not yet present | <itemTypeDate> |
2009-12-16 |
| Symbol | 0 | 1 | string | The symbol used when rendering figures measured in the unit. MUST be absent when the unit is not simple. | <symbol> |
m³ Å € |
| Numerator Item Type | 0 | 1 | NCName | If present, then the unit numerator MUST be for a unit having a measure-to-type match to this item type, if the type is present in the UTR. Numerator Item Type MUST be absent for simple unit definitions |
<numeratorItemType> |
lengthItemType |
| Numerator Item Type Namespace | 0 | 1 | URI | If the namespace of the numerator item type is limited, then it is provided here. If present, then numerator item type MUST be present. Numerator Item Type Namespace MUST be absent for simple unit definitions. |
<nsNumeratorItemType> |
http://www.xbrl.org/dtr/type/numeric |
| Denominator Item Type | 0 | 1 | NCName |
If present, then the unit denominator MUST be for a unit having a measure-to-type match to this item type, if the type is present in the UTR. Denominator Item Type MUST be absent for simple unit definitions |
<denominatorItemType> |
sharesItemType |
| Denominator Item Type Namespace | 0 | 1 | URI | If the namespace of the denominator item type is limited, then it is provided here. If present, then denominator item type MUST be present. Denominator Item Type Namespace MUST be absent for simple unit definitions. |
<nsDenominatorItemType> |
http://www.xbrl.org/2003/instance |
| Definition | 1 | 1 | XHTML mixed | The meaning of the unit, in English. | <definition> |
Millions of US Gallons per Day (Volumetric Flow) |
| Base Standard | 0 | 1 | {ISO4217, SI, Customary, Non-SI, XBRL} | A token indicating the authority or source, such as an [ISO] code list, of the unit definition. | <baseStandard> |
SI |
| Presentation Conversion | 0 | 1 | XML | MathML definition using elements such as <mrow> and <msup> to present a formula for
conversion into standard international base units, if such a conversion exists. |
<conversionPresentation> |
<math>
<mrow> </math><mn>4046.86</mn> <mo>*</mo> <msup> </mrow><mi>m</mi> <mn>2</mn> </msup> |
| Content Conversion | 0 | 1 | XML | MathML definition using elements such as <apply> , <power> and <times> to
present a formula for conversion into standard international base units, if such a conversion exists. |
<conversionContent> |
<math>
<apply> </math><times/> <cn>4046.86</cn> <apply> </apply><power/> <ci>m</ci> <cn>2</cn> </apply> |
| Status | 1 | 1 | {IWD, PWD, CR, REC, NIE, PROPOSED, ACK, RR} | The XBRL International status of this unit.
|
<status> |
PROPOSED |
| Version Date | 1 | 1 | date | Effective date of this version of the unit; all versions of the same unit with earlier dates are effectively superseded. | <versionDate> |
2012-12-21 |
The latest version of the UTR will be placed at a fixed location on the xbrl.org website and will be the file
at the URL http://www.xbrl.org/utr/utr.xml. Each version will also be permanently archived in a
subdirectory whose name contains the date on which it became effective (e.g.
http://www.xbrl.org/utr/2009-01-22/utr.xml). This is analogous to the archival convention for
specification schemas.
A UTR processor tests valid XBRL instances for validity with respect to the UTR.
A QName is a type match to a <utr:unit> if
(a) <utr:itemType> is absent or the local name of the QName equals the content of
<utr:itemType> and (b) <utr:nsItemType> is absent or the QName has no namespace URI or the
namespace URI of the QName is equal to the content of <utr:nsItemType> .
The definition of type match allows a QName to match a type even when the type is not numeric.
<xbrli:durationItemType> names a non-numeric data type, but
durationItemType nevertheless appears in <utr:itemType> of some entries in the UTR
so as to allow for units such as "km/D", where "D" means days.The definition of type match also allows a <utr:unit> to omit
<utr:itemType> type and <utr:nsItemType> and therefore match any type.
A QName is present in the UTR if it
has a type-match to any <utr:unit> whose <utr:status>
equals REC.
The restriction relationship [XML Schema Structures] forms a total order with respect to types.
The most specific ancestor in the UTR of a type is the minimum of that total order.
A <xbrli:measure> is a measure match
to a <utr:unit> if the QName content of the <xbrli:measure> has (a) a local name equal to
the content of the <utr:unitId> element and (b) <utr:unitNamespace> element is absent or the
QName's namespace URI is equal to the content of <utr:unitNamespace> . Note [XBRL 2.1] 4.8.2 requires the <xbrl:measure> content to have a namespace URI.
The base case for matching occurs when the unit is a single measure:
An <xbrli:measure> is a
measure-to-type match to a type if there is a <utr:unit> for which the
<xbrli:measure> is a measure match and the type is a
type match.
An <xbrli:unit> having a <xbrli:divide> child can be said to have matches in the UTR by
recursive definition, as follows:
An <xbrli:divide> is a
division-to-type match to a <utr:unit> if all of the following hold:
<xbrli:unitNumerator> has exactly one <xbrli:measure> child <utr:nsNumeratorItemType> and <utr:numeratorItemType> either
xbrli:unitNumerator/xbrli:measure <xbrli:unitDenominator> has exactly one <xbrli:measure> child <utr:nsDenominatorItemType> and <utr:denominatorItemType> either
xbrli:unitDenominator/xbrli:measure
Note that a <utr:unit> cannot express a constraint on what a numerator or denominator cannot be;
entries with <utr:definition> values that imply such a restriction are describing intended usage, not
validation.
With reference to the UTR sample in Appendix B:
perShareItemType and <xbrli:unit> having numerator
iso4217:JPY and denominator xbrli:shares. There is a division-to-type match because iso4217:JPY is a measure-type match to xbrli:monetaryItemType,
xbrli:shares is a measure-type match to
xbrli:sharesItemType, and the <utr:unit> with <utr:unitID> value
Monetary_per_Share has <utr:nsNumeratorItemType> and
utr:numeratorItemType with a measure-type match
to xbrli:monetaryItemType, and the <utr:unit> with <utr:unitID> value
Monetary_per_Share has utr:nsDenominatorItemType and
utr:denominatorItemType with a measure-type match
to xbrli:sharesItemType. perShareItemType and denominator utr:m have no division-type match because utr:m is not a measure-type match to xbrli:sharesItemType. perUnitItemType and unit having numerator iso4217:JPY and a
denominator with any single <xbrli:measure> have a division-type
match because the utr:unit entry where utr:itemType is
perUnitItemType does not constrain the denominator type and therefore does not constrain the
denominator unit. Even a denominator of iso4217:TND will be a measure-type match match even though such usage violates the intent. A unit has a unit-to-type match to a
type when the defining <xbrli:unit> has either (a) a single <xbrli:measure> child having a
measure-to-type match to that type or (b) an
<xbrli:divide> child having a division-to-type match
to that type.
A simple unit with more than one measure or a unit with more than one measure in either the numerator or denominator can never have a unit-to-type match.
A numeric fact has a type when the post-schema validation infoset (PSVI) of the fact contains the type name [XML Schema Structures].
A fact's most specific type in the UTR is the most specific ancestor in the UTR of its type.
<xbrli:numericItemType> . However, only types B and C are present in the UTR. B is
the most specific ancestor present in the
UTR of A. The @unitRef of an AA fact must resolve to a unit allowed for
type B. Type C is not relevant.A numeric fact has a fact-to-UTR match when its unit has a unit-to-type match with the most specific type present in the UTR of the fact.
A numeric fact is UTR-valid when the fact either (a) does not have a most specific type present in the UTR or (b) the fact has a fact-to-UTR match.
A UTR processor MUST raise an error utre:error-NumericFactUtrInvalid for each numeric fact that is not UTR valid.
An instance is UTR-valid when every numeric fact is UTR-valid.
The definition of any unit that has the status of REC in the UTR is normative.
The definitions of any units with any other status are non-normative and are provided for information only. If a unit has the status of ACK it is not intended that it should ever proceed on the track to having REC status. It MAY have a status in a closed environment that imposes certain requirements on software that is customised for that particular environment, however XBRL International makes no representations whatsoever about such units.
Software vendors are NOT obliged to implement support for UTR validation in order to continue to claim that they support the [XBRL 2.1] base specification.
It is expected that software vendors will make claims regarding which units they support. They MUST point to successful exercise of any relevant conformance suite tests in order to substantiate such claims.
The following is the XML schema corresponding to the data model described in Section 2. It is normative. Non-normative versions (which should be identical to this except for appropriate comments indicating their non-normative status) are also provided as separate files for convenience of users of the specification.
Following the schema maintenance policy of XBRL International, it is the intent (but is not guaranteed) that the location of non-normative versions of these schemas on the web will be as follows: While any
The following is an example of a utr (as defined by the schema in Appendix A above).
<?xml version="1.0" encoding="UTF-8"?> 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.
| Date | Author | Details |
|---|---|---|
| 23 March 2011 | Walter Hamscher |
Initial version based on DTR. |
| 17 April 2011 | Walter Hamscher |
Updated the structure declaration to match the current UTR implementation. |
| 05 May 2011 | Hugh Wallis |
Editorial for publication as PWD. |
| 09 August 2011 | Walter Hamscher |
Copied text from Table 1 to the schema declarations of conversionPresentation and conversionContent, added not regarding numerator and denominator item types, corrected spelling error. |
| 09 November 2011 | Walter Hamscher |
Editorial for publication as CR. |
| 10 December 2011 | Walter Hamscher |
Editorial as DR. |
| 21 December 2011 | Walter Hamscher |
Add column "element or attribute" to Table 2. Clarify that the combination of unitId and nsUnit are unique within the scope of the registry. Correct the text of the unitId description to reflect that it can contain {numerator} or {denominator}. Edit the schema documentation elements to be the same as the explanation in the data model table. Editorial for publication as PR. |
| 30 April 2012 | Walter Hamscher |
Added new Section 4, Validation, other editorial changes for DPR. |
| 08 June 2012 | Paul Warren |
Editorial changes to validation section. |
| 10 June 2012 | Walter Hamscher |
Correct explanation of unitID, add example of division matches in Validation, other editorial changes to Validation. |
| 01 July 2012 | Walter Hamscher |
Copy a utr fragment into the validation section to support its example. Remove all uses of the curly-brace convention to indicate parameterized unit declarations. |
| 18 July 2012 | Paul Warren |
Added definitions for simple unit definition and complex unit definition, and codified constraints relating to them in the list of fields. Clarified definition of Unit ID. Expanded sample UTR in appendix, and referenced sample UTR from explanatory validation section. |
| 31 October 2012 | Walter Hamscher |
Editorial as PR. |
| 30 November 2012 | Walter Hamscher |
Editorial as DPR. |
| 31 December 2012 | Walter Hamscher |
Editorial as PR. |
| 17 May 2013 | Walter Hamscher |
Correct the definition of UTR-valid to accomodate types not present in the UTR. Correct the definition of division-to-type match to accomodate types not present in the UTR, and require numerator and denominator matches without considering ancestor types. Correct Table 2 item type and item type namespace because they are required whether the unit is simple or a division. Alter the schema to reflect all constraints defined in the specification. Add David North as contributor. |
| 18 November 2013 | Walter Hamscher |
Editorial as REC. |
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 Link Role Registry Approval Manager up to and including 18 November 2013. 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.