Units Registry - Conformance 1.0

Candidate Recommendation 18 November 2013

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

This version:
<http://www.xbrl.org/Specification/utr-conformance/CR-2013-11-18/utr-conformance-CR-2013-11-18-clean.html>
Editors:
Walter Hamscher, United States Securities and Exchange Commission
David North, CoreFiling
Contributor:

Status

Circulation of this Candidate Recommendation is unrestricted. This document is normative. Other documents may supersede this document. 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.

Abstract

This document explains the file structure and use of of the Unit Type Registry Conformance Suite.

Table of Contents

1 Introduction
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 Syntax of Test Cases
3 UTR Structure Testing
4 UTR Content Testing
5 Normative Schemas
5.1 UTR Testcases File

Appendices

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

Table

1 Namespaces and namespace prefixes

Definitions

DTR
UTR
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
simple unit definition, complex unit definition, type match, present in the UTR, most specific ancestor in the UTR, measure match, measure-to-type match, division-to-type match, has a type, most specific type in the UTR, fact-to-UTR match, UTR-valid


1 Introduction

The unit registry structure specification defines the syntax of a units registry (UTR) as well as validity of an XBRL instance with respect to any particular version of the registry.

The validity of a registry can be tested entirely against its XML Schema [XML Schema Structures] definition.

To test a processor meant to determine validity of instances with respect to the content of a particular registry file, this conformance suite provides a set of instances along with a characterization of each as "good" or "nogood". A processor that deems all of the good instances to be valid, and all of the nogood instances to be invalid with respect to the UTR conforms to the test suite.

A processor may also be tested with respect to a particular version of a UTR using a set of instances that exercises a representative sample of the unit entries in that version of the UTR.

1.1 Relationship to other work

This document pertains to XBRL as defined in the XBRL Specification [XBRL 2.1] and to the UTR defined in the UTR Structure Specification [UTR STRUCTURE].

1.2 Terminology

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] .

simple unit definition, complex unit definition, type match, present in the UTR, most specific ancestor in the UTR, measure match, measure-to-type match, division-to-type match, has a type, most specific type in the UTR, fact-to-UTR match, UTR-valid are as defined in the UTR Structure Specification [UTR STRUCTURE].

DTR refers to the Data Types Registry that is the subject of a different specification.

UTR refers to the Units Registry that is the subject of this specification.

1.3 Language

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.

1.4 Document conventions

1.4.1 Typographic conventions

1.4.1.1 Definition notation

Definitions are highlighted with green text.

1.4.1.2 Footnote notation

Comments which are informative, but not essential to the understanding of the point at hand, are provided in footnotes. All footnotes are non-normative.

1.4.1.3 Element and attribute notation

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.

1.4.2 Formatting conventions

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.

1.5 Namespaces and namespace prefixes

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.

Table 1: Namespaces and namespace prefixes
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
conf http://xbrl.org/2005/conformance

2 Syntax of Test Cases

Each test case is described in a document having root element <testcase> . A single testcase consists of a number of variations, with each <variation> containing a description of the input files and the expected errors or warnings that a conforming processor must emit to indicate that the set of inputs consitutes an "invalid" or "nogood" input. A variation with no expected error or warning results means that the conforming processor must emit no errors or warnings and is "valid" or "good". Therefore, a processor will "pass" or "fail" each variation depending on whether it produces the expected result, be that valid or invalid. The variations are grouped according to topics covered in the UTR structure specification [UTR STRUCTURE].

An "index" file contains elements defining the location of each testcase within a test suite.

3 UTR Structure Testing

Folder conf/utr-structure/malformed-utrs contains a set of UTR registry files that are XML Schema-invalid. There is one file per MUST requirement in [UTR STRUCTURE]. There is no testcase file provided because ordinarily it is is not the UTR processor itself responsible for ensuring the validity of the registry.

Folder conf/utr-structure/index.xml contains references to a set of individual testcase files covering validation cases including simple units, division units, supertype matching and QName matching [UTR STRUCTURE]. Folder conf/utr-structure/taxonomy contains a simple taxonomy used in these testcases. Implementations may wish to use the conf/utr-structure/catalog.xml file to avoid internet access for the DTR schemas; local copies are in conf/utr-structure/schemas.

Note that these testcases all depend on the use of a specific utr file, conf/utr-structure/utr-for-structure-conformance-tests.xml. A processor being tested for compliance with the UTR structure specification requires some means of using that file instead of the published utr file at http://www.xbrl.org/utr/utr.xml (file conf/utr-structure/catalog.xml does not contain a remapping entry for utr.xml).

4 UTR Content Testing

Each published version of the UTR implicitly defines a set of variations derived from the individual unit entries. In addition to testing a UTR processor for general compliance with the UTR structure validation process, implementors may wish to verify that their processor correctly implements a specific UTR version. Folders named conf/utr/YYYY-MM-DD contain an index.xml file and supporting files for each version of the UTR published on YYYY-MM-DD.

5 Normative Schemas

5.1 UTR Testcases File

<xs:schema
  xmlns:xs
="http://www.w3.org/2001/XMLSchema"

  xmlns:conf
="http://xbrl.org/2005/conformance"

  xmlns:xbrli
="http://www.xbrl.org/2003/instance"

  xmlns:xbrldt
="http://xbrl.org/2005/xbrldt"
targetNamespace="http://xbrl.org/2005/conformance" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:complexType name="inputFileType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="readMeFirst" type="xs:boolean" use="optional" default="false"/>
<xs:attribute name="schemavalid" type="xs:boolean" use="optional" default="true"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="xsd" type="conf:inputFileType"/>
<xs:element name="linkbase" type="conf:inputFileType"/>
<xs:element name="instance" type="conf:inputFileType"/>
<xs:element name="data">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element ref="conf:xsd"/>
<xs:element ref="conf:linkbase"/>
<xs:element ref="conf:instance"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="result" type="conf:resultListType">
<xs:annotation>
<xs:documentation>The result of a test is a list of errors, warnings and inconsistencies</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="resultListType">
<xs:choice maxOccurs="unbounded" minOccurs="0">
<xs:element ref="conf:file"/>
<xs:element ref="conf:error"/>
<xs:element ref="conf:warning"/>
<xs:element ref="conf:inconsistency"/>
</xs:choice>
</xs:complexType>
<xs:element name="file">
<xs:simpleType>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:element>
<xs:element name="error">
<xs:simpleType>
<xs:restriction base="xs:QName"/>
</xs:simpleType>
</xs:element>
<xs:element name="warning">
<xs:simpleType>
<xs:restriction base="xs:QName"/>
</xs:simpleType>
</xs:element>
<xs:element name="inconsistency">
<xs:simpleType>
<xs:restriction base="xs:QName"/>
</xs:simpleType>
</xs:element>
<xs:element name="description">
<xs:complexType mixed="true">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="referenceURI" type="xs:anyURI" use="optional"/>
<xs:attribute name="reference" type="conf:referenceType" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="referenceType">
<xs:annotation>
<xs:documentation>This is a reference to a title in a document. The pattern is of the form "filename#1.2.3"</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value=".*#([0-9])+(\.[0-9]+)*"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="variation">
<xs:complexType>
<xs:sequence>
<xs:element ref="conf:description"/>
<xs:element ref="conf:data"/>
<xs:element ref="conf:result"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="optional"/>
<xs:attribute name="name" use="required">
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="testcase">
<xs:complexType>
<xs:sequence>
<xs:element ref="conf:variation" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="description" type="xs:string" use="required"/>
<xs:attribute name="outpath" type="xs:string" use="required"/>
<xs:attribute name="owner" type="xs:string" use="required"/>
<xs:attribute name="minimal" type="xs:boolean" use="optional" default="true"/>
</xs:complexType>
</xs:element>
</xs:schema>

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)
UTR STRUCTURE
XBRL International Inc.. "Units Registry - Structure 1.0"
Hugh Wallis
, and Walter Hamscher.
(See http://www.xbrl.org/Specification/utr/PR-2013-05-17/utr-structure-PR-2013-05-17.html)
XBRL 2.1
XBRL International Inc.. "Extensible Business Reporting Language (XBRL) 2.1 Includes Corrected Errata Up To 2013-02-20"
Phillip Engel
, Walter Hamscher, Geoff Shuetrim, David vun Kannon, and Hugh Wallis.
(See http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31+corrected-errata-2013-02-20.html)
XML Names
W3C (World Wide Web Consortium). "Namespaces in XML 1.0 (Third Edition)"
(See http://www.w3.org/TR/2009/REC-xml-names-20091208)
XML Schema Structures
W3C (World Wide Web Consortium). "XML Schema Part 1: Structures Second Edition"
Henry S. Thompson
, David Beech, Murray Maloney, and Noah Mendelsohn.
(See http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/)

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
17 May 2013Walter Hamscher

Initial version.

18 November 2013Walter Hamscher

Editorial for REC.

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