1. Introduction

1.1 Scope and Purpose

The purpose of this Style Guide is to facilitate the creation of consistent, high-quality, easy-to-use taxonomies by serving as a basis for the naming styles of XBRL concepts, labels and other components. This Style Guide should be followed for taxonomy development and architecture for all taxonomies, including for open and extendable taxonomies, created and used in the United States.

Deviations from Style Guide Specifications should be substantiated and noted in a supplement to the taxonomy guide that corresponds to the deviating taxonomy.

This 2017 Style Guide is intended for use by developers in new taxonomy development. Taxonomies created prior to 2017 may not adhere to Style Guide Specifications. Governing bodies are encouraged to consider adopting the Style Guide in subsequent or revised taxonomy releases.

1.2 Goals

Consistency in all aspects of XBRL, including style, is critical to the successful deployment of the XBRL standard. Consistent styling of concept names, labels, and documentation will facilitate the efficient creation and consumption of XBRL data.

The primary goals of this document are the following:

1. Provide a basis for the consistent development and maintenance of US taxonomies.
2. Increase the efficiency and effectiveness of US taxonomies.
3. Improve taxonomy extensibility for end users and taxonomy developers.
4. Maximize comparability of data, reduce the ambiguity of data, and promote the normalization of data.
5. Increase compatibility of taxonomies.
6. Improve the reliability and consistency of the concepts, labels and documentation.
7. Reduce the cost of taxonomy implementation.

These goals can be achieved through standardization. An effective standard for taxonomy creation will provide developers with the tools to create consistent taxonomies, resulting in taxonomies that end users can effectively navigate. Standard taxonomies can be adopted more quickly by end users, reducing the time and cost associated with implementing and consuming XBRL.

This Style Guide promotes adherence to XBRL International Incorporated (XII) and XBRL US (XUS) best practices, as applicable to style. Other XII and XUS best practices should also be followed during taxonomy creation for topics that are not covered by this guide.

1.3 Conventions

The following highlighting is used for non-normative commentary in this document:

Non-normative editorial comments are denoted by indentation and the prefix “NOTE:”

NOTE : This is a non-normative editorial comment.

Normative requirements will contain capitalized 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.

All specifications within this document are considered normative except those marked as non-normative.

1.4 Terminology

The terminology used in XBRL frequently overlaps with terminology from other fields. The following list is provided to reduce ambiguity and confusion.

Table 1. Terms and Definitions

1.5 Style Guide Position and Reference Materials

This guide serves in a larger scheme of specification and other published materials:

Figure 1. Style Guide Position

At the lowest level are documents such as the XML specifications and other materials related to the XML specification. This is the foundation for the XBRL specifications from XII, which include a variety of documents.

The Style Guide serves as a foundation for Taxonomy development and maintenance in the United States with the Style Guide’s governance controlled by XUS.

Taxonomies themselves may incorporate other taxonomies developed and controlled by other government entities and/or non-government organizations (NGOs). In addition, many NGOs control or contribute to various taxonomies while government agencies can contribute to and approve such taxonomies.

Taxonomies included in a Compliant Taxonomy do not have to be compliant. It is the purview of the authors of those incorporated taxonomies to comply with the rules set forth in the Style Guide. For more information on Taxonomy development, refer to the XBRL US Taxonomy Guide.

Return to Table of Contents

2. Data Organization and XBRL Conventions

Data organization is paramount when creating a Compliant Taxonomy. Compliant Taxonomy developers SHOULD review the Taxonomy Guide before beginning XBRL taxonomy creation for additional information about creating and analyzing the Semantic Data Model.

The structure and style of the resulting taxonomy impacts software developers, preparers of data, and analysts, as well as systems that generate and receive data. A significant strength of XBRL is data organization and the ability to describe, examine, and compare data. Authors should consider how the end data might be explored and whether the data structure, concepts names, and labels are conducive to allowing users to utilize the strengths of XBRL.

Developing the Taxonomy Vernacular should not be seen as a second part of the taxonomy development process that occurs after the Semantic Data Model has been completed. Neither should the development of the Semantic Data Model occur after developing the Taxonomy Vernacular.

Rather, creating a Compliant Taxonomy will be an iterative process that involves making changes to the Semantic Data Model during the development of the Taxonomy Vernacular. Shortcomings will become apparent in even the most well-prepared data models as Developers attempt to assign language and describe each element in the model. For example, Developers may find that certain data requires restructuring, that there are redundancies that need to be eliminated, or that certain Subjects require additional Concepts for further granularity.

Figure 2. Taxonomy Creation Workflow

Part of taxonomy style is organizing the Semantic Data Model. Proper organization of the Semantic Data Model will aid Developers in structuring the taxonomy, determining Concepts, and selecting language for each Concept’s Label Roles. Combined with the Functional Requirements and XBRL Requirements, an initial Taxonomy Vernacular can be created. Imported Taxonomies will likely be included which can also influence the design process. During the design cycle, the iterative process continues until the Taxonomy is approved and ready for the stakeholders. Changes may flow back into both the Semantic Data Model and the Functional Requirements as discrepancies, missing items, or other errors are discovered.

The Developer SHOULD avoid overlapping or redundant data points. Such points may make sense in the description of the Semantic Data Model but not when applied to the Taxonomy. However, the same concept can appear in more than one presentation within the Taxonomy.

The “Structure” aspect of “Concepts & Structure” is important in terms of how the various features of XBRL are employed and can heavily impact the naming of Concepts. XBRL defines a fact to be an intersection of a Concept, a Context and a unit. On a basic level, Contexts provide the time dimension to a fact but can be further expanded by defining additional dimensionality through the use of member and scenario Concepts. Concept hierarchy can be expressed using presentations and calculations as well. These different methods of structuring data can impact how Concepts are named and where dimensions and dimensional Concepts may be more appropriate than individual Concepts.

Finally, the design of the Taxonomy Vernacular should take into consideration extensibility, the revision process and the ease of understanding.

Return to Table of Contents

3. Language Guidelines

Language Guidelines MUST be followed for all Taxonomy Vernacular. This includes Labels, Concepts, and Roles. A well-structured, easily understandable taxonomy flows down from the guidelines set forth in this section. It is critical for authors to employ this as a minimum basis in developing clear and concise taxonomy structure.

Language Guidelines in other sections that are specific to Labels or Concept names supersede the rules here where conflicts occur.

For the purposes of creating Compliant Taxonomies within the United States, Developers SHOULD create the taxonomy using American English and use the XML language identifier to indicate “en-US” as the language for the taxonomy. Additional languages MAY be included in the taxonomy by creating a specific Label Role for that language. However, in all Compliant Taxonomies, Concept names, the Standard Label, and the Documentation Label SHOULD be written using grammar and spelling common to American English.

NOTE : The language guidelines contained within this Style Guide pertain to Taxonomy Vernacular written in American English. Within any language Label for an additional language, Developers should use the proper grammar, spelling, and conventions of that language while following the rules set forth in the Style Guide to the extent possible.

3.1 Use of Articles/Adjectives

Articles SHOULD be restricted to Documentation Labels.

Table 2. Restricted Articles

Adjectives MUST be used with a noun.

Adjectives MUST be used when there is ambiguity surrounding the subject.

3.2 Nouns

Each item in the Taxonomy Vernacular SHOULD contain a noun. The data being modelled by the taxonomy refer to specific subjects and objects (such as finances, employees, equipment, etc.) and therefore the Taxonomy Vernacular should use nouns to describe the data.

3.3 Pronouns

Personal Pronouns MUST NOT be used.

Possessive Pronouns MUST NOT be used.

Other Pronouns SHOULD NOT be used except in Documentation Labels.

Table 3. Disallowed Pronouns

NOTE : Many of the words in Table 3 can be used as pronouns, adjectives or nouns in the English language. This rule refers specifically to their usage as pronouns.

Gender neutral personal pronouns such as “ze” or “xe”, which are gaining adoption in many countries including the United States, should be considered the same as traditional personal pronouns and MUST NOT be used in Taxonomy Vernacular.

3.4 Adverbs

Adverbs SHOULD NOT be used. Adverbs MAY be used to express a recurring Subject.

Example 1. Allowable Use of Adverbs

3.5 Expressing Numbers

Use the following rules for numbers:

– Exact numbers one through nine MUST be spelled out, except for percentages and page or section numbers.

– Numbers of 10 or more MUST be expressed in figures.

3.6 Spelling and Alternative Terms

3.6.1 Spelling

For words that have multiple correct spellings, developers SHOULD use agreed-upon spelling as noted in Table 4 below. Words not in this list MUST be spelled consistently throughout the taxonomy.

Table 4. Agreed-upon Spellings

3.6.2 Alternative Terms

Alternative terms in the Taxonomy Vernacular SHOULD be avoided. If a subject can be described using alternative terms, those terms most widely used in practice SHOULD be used in the taxonomy. The selected term MUST be used consistently throughout the Taxonomy Vernacular.

Developers SHOULD avoid using synonyms for both nouns and adjectives within the Taxonomy Vernacular.

3.7 Use Concise Descriptions

All Taxonomy Vernacular MUST be concise, follow commonly used terminology, and avoid being excessively descriptive. Language used should avoid Labels that reference other line items on a financial statement.

Example 2. Concise Language and Common Terminology

3.8 Use of Units

Concept names and Labels MUST NOT specify the unit of the data being described.

3.9 Use of Scaling

Concept names and Labels MUST NOT specify scaling.

3.10 Use of the Word “Other”

The word “Other” SHOULD NOT be used by itself or solely in conjunction with an adjective. The word “Other” SHOULD be used only when there are groups of like items in the Taxonomy Vernacular. A Label or Concept that describes all other data does not make sense without another Label or Concept that describes a specific portion of that data.

The term “Miscellaneous” SHOULD NOT be used; “Other” should be used instead, provided that it adheres to the proper use rule as noted above.

Example 3. Acceptable Use of the Word “Other” Within A Group of Subjects

3.11 Use of the Word “Total”

The word “Total” SHOULD be used only for the Total Label Role.

3.12 Use of Terms of Art as Adjectives

Developers MAY use “terms of art” within the Taxonomy Vernacular provided the term of art is defined in supporting user and preparer guides for the Compliant Taxonomy.

Example 4. Using a Term of Art

Developers MAY shorten certain “terms of art” to a single adjective within the Compliant Taxonomy, provided that such use follows the additional rules below:

1. The adjective when used alone is only used to represent the term of art.
2. The term of art does not appear in any Concept names or Labels with the exception of the Documentation Label.
3. If multiple terms of art could be shortened to the same adjective, only shorten the most common term as it appears in the taxonomy.

Example 5. Shortening a Term of Art to a Single Adjective

3.13 Characters/Character Set

The Taxonomy Vernacular SHOULD contain only characters from the Unicode Latin code charts.

The following characters MUST NOT be used:

Table 5. Disallowed Characters

Developers SHOULD avoid using symbol characters except in the Documentation Label.

3.14 Percentages

The word “Percent” SHOULD be spelled out except when used in Documentation Labels. When Documentation Labels contain an example with percentages, numerical percentages SHOULD be expressed by using the percent symbol (%).

Return to Table of Contents

4. Concepts

4.1 Common Concepts

Concepts that exist in other taxonomies MUST NOT be recreated as part of a Compliant Taxonomy; rather, a Compliant Taxonomy MUST reference the other taxonomy by importing its namespace. When incorporating existing taxonomies, the Style Guide SHOULD be employed for consistency purposes, even if the imported taxonomy is not a Compliant Taxonomy.

For a list of available taxonomies that have been approved, see https://xbrl.us/us-taxonomies.

4.2 Organization of Concepts

Elements in the same topic area SHOULD be associated through the use of abstract elements and presentation structure.

4.3 Language Usage

The guidelines stated in 3. Language Guidelines
also apply to Concepts. The section below provides additional guidance specific to language associated with Concept names.

4.3.1 Use of Dashes

Dashes SHOULD NOT be used in Concept names.

4.3.2 Acronyms and Abbreviations

Acronyms and abbreviations MAY be used in Concept names if the acronym itself is more commonly understood by target end users than the acronym’s meaning or if the length of the expanded acronym would be prohibitively long. When using an acronym, all letters in the acronym SHOULD be capitalized.

Example 6. Acceptable Concept Name
Containing an Abbreviation or Acronym

Example 7. Unacceptable Concept Name
Containing an Abbreviation or Acronym

When an acronym or abbreviation is used as part of a Concept name, at least one of the Concept’s Labels SHOULD contain the spelled-out version. Brevity is important in Concept names but clarity to the user is more important.

4.4 Word Ordering and Use of Adjectives

4.4.1 Word Ordering

Consistent ordering of words in the Taxonomy Vernacular is important as it helps end users and consumers identify similar items. The goal is to create language that is consistent and easy to read.

Each Concept name MUST follow the same pattern:

{Noun} ({Adjective} …)

Any number of adjectives MAY follow the noun when describing the Subject of the Concept. Adjectives used in more than one Concept MUST appear in the same order throughout the Taxonomy Vernacular.

Open compound, closed compound and hyphenated compound nouns SHOULD be treated as the noun in the word order.

Example 8. Proper Use of the Noun Before Adjectives Pattern

4.4.2 Adjective Order

The Developer should consider that Concepts are often sorted alphabetically by end users without regard to Concept relationships.

When multiple adjectives are being used to modify a noun, the order of precedence set in Table 6. Adjective Order MUST be followed.

Table 6. Adjective Order

Developers SHOULD NOT use adjectives related to quantity in Concept names.

4.5 Concept Naming

4.5.1 Concept Naming Rules

Concept names SHOULD be derived from the Subject they represent. Concept names MUST follow the XBRL 2.1 specification for element names.

Concept names SHOULD adhere to upper camel case. Upper camel case requires that each word in the Concept name begins with a capital letter with no intervening spaces or punctuation. The initial letter in a Concept name must be an upper case letter.

Example 9. Upper Camel Case Concept Names

Use the following additional rules for naming Concepts:

• The first character of the Concept name MUST be a capitalized letter.
• The Concept name MUST NOT contain special characters as defined by XML naming restrictions.
• The Concept name MUST NOT contain the word “Total” or any synonym of that word. The fact that a value is a “total” SHOULD be expressed using calculation relationships.
• Optionally, connective words and conjunctions that normally would be used to describe the Concept’s subject MAY be omitted from the Concept name provided that such omissions are consistent throughout the Compliant Taxonomy.

4.5.2 Concepts and Data Types

Concepts MUST use data types from the XBRL 2.1 specification or data types included in the Data Type Registry (DTR) . New data types MAY be created but SHOULD be more restrictive forms of the data types specified by XBRL 2.1 or the Data Type Registry.

Data that can be expressed using multiple data types SHOULD have multiple Concepts to describe it. In this instance, each Concept SHOULD have a name that reflects its data type. Concepts that have a single data type do not need to indicate the data type in its name.

Concept names for Concepts that describe nonmonetary data MUST contain a descriptor indicating the type of data the Concept represents. This is to avoid having Concepts with different data types that have indistinguishable names. Users should be able to determine which Concept to use for data without the need to reference a Concept’s data type.

Example 10. Concepts with Names That Express Data Type

4.5.3 Concepts and Dimensions

Concept names that express dimensional components SHOULD contain the appropriate component name at the end of the Concept name, as per the rules below:

• Member Concepts SHOULD end with “Member.”
• Axis Concepts SHOULD end with “Axis.”
• Domain Concepts SHOULD end with “Domain.”
• Line item Concepts SHOULD end with “LineItem.”
• Table Concepts SHOULD end with “Table.”

4.5.4 Concepts and Tuples

Each tuple MUST have a companion Concept that facilitates searching, for consumers, by providing a textual version of the tuple data as a single value. Additionally, providing this Concept helps to organize the taxonomy and makes it more readable.

This equivalent Concept SHOULD have a name that is the plural form of the subject of the tuple. This is because the textual equivalent Concept will contain all data tagged by the tuple.

4.6 Financial Term Guidance

4.6.1 Guidance for Using Financial Terms in Concept Names

Direct cash flow Concepts MUST contain “Proceeds” for Concepts describing cash inflows and “Payments” for Concepts describing cash outflows.

Indirect cash flow Concepts MUST use “IncreaseDecrease” or “FromUsedIn” for net Concepts.

Example 12. Proper Naming for Cash Flow Concepts

Concepts that represent data valued “at Cost” or “at Fair Value” SHOULD describe the valuation method in the Concept name. This description SHOULD appear after the noun and use “at” to represent “valued at”.

Example 13. Proper Naming for Valuation Concepts

4.6.2 Preferred Adjectives for Accounting

The following preferred adjectives MUST be used:

Table 7. List of Preferred Adjectives for Data

Return to Table of Contents

5. Labels

5.1 Overview of Labels

The guidelines in this section apply to all Labels, including the Documentation Label. There are additional guidelines for Documentation Labels in 6. Guidelines for Documentation Labels of the Style Guide.

Two common errors that domain experts make while trying to create a taxonomy are worth noting:

(a) using a sentence from a disclosure checklist as the Label; and

(b) accepting a financial statement or other line item description as a Label,

without verifying that either of the above accurately and sufficiently describes the expressed Concept.

It is the task of the taxonomy developer to provide the shortest possible Label which contains sufficient information to describe the meaning of a Concept. The precise meaning of a Concept is provided by taxonomy documentation, references and element relationships. However, it is valuable to users and consumers to be able to accurately discern the meaning of a Concept without needing to reference the documentation or other materials.

The primary goals of creating a standard form for all Labels within a taxonomy are:

1. To provide users with Labels that are clear and consistent and that minimize the need to use documentation resources or other reference materials to ensure data is being tagged by the correct Concept.
2. To provide enough information within Labels to maximize Label usability and uniqueness, while minimizing Label length and complexity.

Taxonomy developers MUST provide, at a minimum, one unique Standard Label and one unique Documentation Label for every Concept in the Compliant Taxonomy. Users should not be required to refer to the Concept name to ensure that they have the appropriate Concept.

5.2 Label Roles

Before creating Labels, the taxonomy developer MUST determine the Label Roles for the taxonomy. All Compliant Taxonomies MUST have a Standard Label Role and MUST have a Documentation Label Role. All other Label Roles are optional and can be used to apply specified characteristics to a Concept. If a Concept is expected to be used with a particular Label Role, Developers MUST include a Label for that Label Role.

Developers SHOULD refer to the XBRL 2.1 specification Table 8 for standard Label Role attribute values and the XII Link Role Registry (LRR) prior to creating new Roles for the Compliant Taxonomy. Developers MAY create new Label Roles for usages not specified in Table 8 or the LRR.

It is RECOMMENDED that the Standard Label Role matches the Concept name with proper punctuation, capitalization, and spacing with human-relatable word ordering.

It is recognized that taxonomy revisions may result in changes to the Standard Label Role. In such cases, the Standard Label Role will not match the original Concept name. Concept names SHOULD NOT be changed during taxonomy revision due to a revision of the Standard Label. A common reason for a Standard Label change would be a governing body making a change to the nomenclature surrounding a Concept. The Subject of the Concept has remained the same, while the language used by humans to describe it has changed. In this case, the Standard Label would be revised; the Concept would not.

5.3 Language Usage

The guidelines stated in 3. Language Guidelines
also apply to Labels. The section below provides additional guidance specific to language associated with Labels.

5.3.1 Use of Dashes

Dashes SHOULD NOT be used in Labels (except tuples) where commas can be used instead. For example, DO NOT use “Assets – Current”, but rather use “Assets, Current.”

Dashes MUST NOT be used to represent a minus sign. Dashes MUST NOT be used to represent a range. A range in a Label SHOULD be spelled out using “to”.

5.3.2 Acronyms

Acronyms SHOULD be spelled out, followed by the acronym initials in parentheses.

Acronyms MAY be used alone if the acronym itself is more commonly understood by the target end users than the acronym’s meaning. When using an acronym, all letters in the acronym SHOULD be capitalized.

5.3.3 Abbreviations

Abbreviations SHOULD NOT be used in Labels except in the Documentation Label.

When abbreviations are used, usage MUST be consistent.

Periods MAY be used in abbreviations, but period usage in abbreviations MUST be consistent.

5.3.4 Comma Usage in Lists

In a series of three or more items, commas MUST be used after each item, including the penultimate item. A comma SHALL be used before the final “and.”

Example 11. Acceptable Comma Usage in a List

5.3.5 Combinations

The combination “and/or” SHOULD NOT be used. Use “and” to express “and/or.”

5.3.6 Expressing Numbers

Use the following additional rules for numbers in Labels:

• Labels SHOULD NOT start with a number.
• Numbers SHOULD be treated alike throughout a Label; do not use figures for some and spell out others. If the largest number is 10 or more, use figures for all numbers. For example, “Investments, Year 6 Through 10”.
• At the beginning of a sentence in the Documentation Label, a number that would ordinarily be written in figures SHOULD be spelled out, regardless of the inconsistency this may create.
• (OPTIONAL) When a Label contains an example with numbers, those numbers do not need to be spelled out.

Example 12. Acceptable Use of Numbers in Labels

5.4 Capitalization

Labels except the Documentation Label SHOULD use title capitalization as set forth below:

• Capitalize nouns, pronouns, verbs, adjectives, adverbs and subordinating conjunctions.
• Do not capitalize articles, prepositions, coordinating conjunctions and “to” if using an infinitive.

5.5 Hyphen Usage

Generally, words formed with the following common prefixes SHOULD NOT be hyphenated.

Table 8. Common Prefixes

Developers SHOULD use the following rules for hyphens:

• Use a hyphen if the second element is a proper noun, a capitalized word, or a numerical figure.

• Use a hyphen if it is necessary to distinguish homonyms.
• Use a hyphen if the second element consists of more than one word.
• Use a hyphen to avoid doubling a vowel (except after the short prefixes co, de, pre, pro, and re, which generally are printed solid).
• Use a hyphen before a compound term.
• Use a hyphen to separate the repeated terms in a double prefix.
• Use a hyphen when a prefix or combining form stands alone.
• Use a hyphen as part of adjectival phrases.
• Use a hyphen in compound terms if a root word ends in a double consonant and its suffix begins with the same consonant.
• Use a hyphen in compound terms if the first element is a proper name.

Example 13. Examples of Proper Hyphen Usage

5.6 Label Descriptions

5.6.1 Labels for Numerical Concepts

For Concepts that represent nonmonetary or nontext data, the corresponding Label(s) SHOULD start with an appropriate descriptor. These include Concepts that are decimals, percentages and dates.

Table 9. Common Appropriate Descriptors to Begin a
Label for a Nonmonetary or Nontext Concept

5.6.2 Labels for Textual Concepts

For Concepts that represent textual data, the corresponding Label(s) SHOULD start with an appropriate descriptor that explains the nature of the text.

Table 10. Common Appropriate Descriptors to
Begin a Label for a Textual Concept

5.6.3 Sign Representation

For Concepts that can be either negative or positive, the Concept Label MUST use parentheses () to indicate which Concept will be represented as negative values in the instance document. Parenthesis MUST NOT be used for other purposes.

There are occasions in an instance document when the value of a Concept could be either positive or negative. A space SHOULD appear between the positive item and the opening parenthesis. A slash SHOULD NOT be used. The positive item should always appear before the negative item.

Example 14. Proper Sign Representation Within Labels

5.6.4 Total Labels

The word “total” or any synonym of “total” SHOULD be used only for the Total Label Role.

5.6.5 Authoritative References

Labels SHOULD NOT include the name of authoritative literature. Developers SHOULD use the reference linkbase to add references to Concepts.

Labels MAY contain references when the Concept describes a change due to a specific rule change or update from a governing body where the reference distinguishes the Concept from similar Concepts.

5.6.6 Period Start and Period End Labels

Labels using the period start Label Role MUST end in the following phrase “, Beginning Balance”.

Labels using the period end Label Role MUST end in the following phrase “, Ending Balance”.

5.6.7 Labels for Tuples

The Label for the tuple Concept MUST follow the normal Label guidelines from this guide.

All Tuple Labels MUST be singular.

Each Concept used in the tuple MUST have a Label in the following format:

{Tuple Label} – {Label describing the second Concept}

In the case of nested tuples, developers SHOULD only use the Label of the tuple which directly holds the item when creating the Label.

Developers MAY shorten the Tuple Label for the Labels of Concepts in the tuple as the Labels may get exceedingly large.

Example 15. Tuple Labels

Example 16. Shortened Tuple Labels

Tuple Concepts SHOULD have a textual equivalent Concept. This equivalent Concept SHOULD have a Label that begins with “Schedule of” followed by a plural version of the Label of the tuple.

Example 17. The Label for a Textual Equivalent Concept to a Tuple

5.7 Label Suffixes

Label suffixes add clarity to the taxonomy structure. Suffix types MUST be contained in brackets [ ] and brackets MUST only be used to denote suffix types.

The “[Abstract]” suffix MUST be used to delineate abstracts Concepts. This section contains additional Label suffixes that are RECOMMENDED but not required. If one suffix type other than “[Abstract]” is used, all suffix types MUST be used.

5.7.1 Abstract

Developers MUST append the suffix “[Abstract]” to the Label for abstract Concepts.

5.7.2 Axis

Developers MAY append the suffix “[Axis]” to the Label for hypercube Concepts.

5.7.3 Domain

Developers MAY append the suffix “[Domain]” to the Label for dimensional member Concepts used as the dimension-default Concept.

5.7.4 Members

Developers MAY append the suffix “[Member]” to the Label for dimensional member Concepts.

5.7.5 Line Items

Developers MAY append the suffix “[Line Items]” to the Label for dimensional line item Concepts.

5.7.6 Table

Developers MAY append the suffix “[Table]” to the Label for table Concepts.

5.7.7 Default

Developers MAY append the suffix “[Default]” to the Label for the default member that is not the domain.

5.7.8 No Default

Developers MAY append the suffix “[No Default]” to the Label for typed dimensions.

5.7.9 Text Blocks

Developers MAY append the suffix “[Text Block]” to the Label for Concepts that express large portions of textual data such as a Note.

5.7.10 Deprecated Concepts

Developers MUST append “[Deprecated]” to the Label for Concepts that are to be retired and should not be used by preparers.

5.7.11 Other Suffixes

Developers MAY append other suffixes to the Labels for Concepts to aid end users in identifying groups of Concepts that pertain to similar disclosures or that are structurally alike. Developers SHOULD be consistent in the use of other suffixes.

Return to Table of Contents

6. Guidelines for Documentation Labels

The guidelines stated in 5. Labels also apply to the Documentation Label. The section below provides additional guidance specific to language associated with the Documentation Label.

All Concepts MUST have a Documentation Label that accurately and concisely describes the Concept and its properties. The Documentation Label SHOULD help the users differentiate between similar Concepts in the taxonomy.

Words that are disallowed in other Label Roles MAY be used in the Documentation Label as part of the explanation for a Concept unless otherwise stated in this Style Guide.

6.1 Creating Accurate Documentation Labels

The goal of the Taxonomy Vernacular is to enable end users to identify Concepts without using outside reference materials. The Documentation Label MUST be used to provide information about the nature of a Concept such that an end user or consumer can clearly understand the tagged data. Therefore, the documentation Label SHOULD contain enough information to clarify questions end users might have about the intended use of a Concept. However, the Documentation Label SHOULD NOT contain so much outside information as to make Concept decisions overly time-consuming or complex.

Concepts MAY be derived from a governing document for the data. This governing document will aid developers in providing clear and consistent Documentation Labels for end users. If no governing documents are available, then the Compliant Taxonomy will become the governing document.

Documentation Labels derived from a governing document SHOULD be conformed to the Style Guide.

The Documentation Label SHOULD contain the following components in the order stated below:

1. The Documentation Label SHOULD first identify the data type of the Concept using plain English.
2. The Documentation Label SHOULD secondly include a description of the Concept derived from a governing document, authoritative literature or other resources.
3. The Documentation Label SHOULD thirdly identify the components of the Concept (if applicable).
4. The Documentation Label SHOULD fourthly identify the components that the Concept does not include when such components are included in a related Concept.
5. (OPTIONAL) The Documentation Label can fifthly include the format of the data when clarification is needed.

Use the following guidelines when forming the description of the Concept:

• Developers SHOULD NOT include accounting recognition or measurement guidance.
• Developers SHOULD NOT include the Standard Label of the Concept in the Documentation Label.
• Developers SHOULD NOT include a reference to specific rules or regulations in the Documentation Label but rather use the reference linkbase. Documentation Labels MAY contain references when the Concept describes a change due to a specific rule change or update from a governing body where the reference distinguishes the Concept from similar Concepts.

6.2 Punctuation

Developers SHOULD use full sentences in the Documentation Label where possible. The Documentation Label MUST end with a period.

Return to Table of Contents

7. References

The following guidelines apply for creating references.

7.1 Reference Consistency

All reference parts MUST be consistent across the entire taxonomy framework. This is particularly true of the publisher and regulation name.

7.1.1 Distinct References

Each reference SHOULD be a distinct reference. A reference link should not consolidate reference components.

Example 18. Shortened Tuple Labels

7.1.2 Presentational References

For presentational disclosure references the presentation Reference role attribute MUST be used. (http://www.xbrl.org/2003/role/presentationRef).

7.1.3 Released Taxonomy Versions

To indicate changes to the taxonomy over time the change note role defined by the FASB SHOULD be used. [requires further documentation and should be part of XUS guidance, perhaps the same so as to not conflict with FASB, see http://www.fasb.org/jsp/FASB/Page/SectionPage&cid=1176160285739]

TaxonomyVersion: Taxonomy Version in CCYY format.

ChangeDate: Date change was made in the taxonomy in CCYY-MM format.

SourceName: Source for change label. Examples include: Extraordinary Items; Revenue Recognition

NewElement: Identifies new elements

ElementDeprecated: Identifies deprecated elements

ModifiedDeprecatedLabel: Identifies modified Deprecated Label

ModifiedReferences: Identifies reference changes

ModifiedLabels: Identifies modified Standard, Period Start, Period End, or Total Labels

ModifiedDocumentation: Identifies modified Documentation Label

PreviousDocumentation: Provides the definition (documentation label) of the element as defined from the prior version of the Taxonomy

DeprecatedDate: Deprecation date in [CCYY-MM] format

DeprecatedLabel: Provides the details of the deprecated element. Specifically, the reason that the element was deprecated and the new elements that may be used, if applicable

ModifiedBalanceType: Identifies that the balance type attribute on an element has been adjusted

ModifiedPeriodType: Identifies that the period type attribute on an element has been adjusted

ModifiedDataType: Identifies that the data type attribute on an element has been adjusted

7.1.4 Taxonomy Specific Reference Roles

Taxonomy specific references can be defined but they must not replicate reference roles already defined by XBRL.org, fasb.org or xbrl.us.
[are there any SEC?]

7.2 Standard Reference Roles

References MUST be identified by the standard reference role. The XBRL Specification offers several roles for identifying the type of reference that is being used. URI’s should only be included if links are guaranteed to be stable through time.

7.3 Reference Changes

Reference parts that contain a URI should only be included if links are guaranteed to be stable through time.

Appendices

A References (non-normative)

Walter Hamscher (editor), Hugh WallisUCUM

The Unified Code for Units of Measure

Schadow, G. and C. J.  McDonald.

http://aurora.rg.iupui.edu/~schadow/units/UCUM/ucum.htmlRFC2119Key words for use in RFCs to Indicate Requirement Levels, March 1997. Scott Bradner http://www.ietf.org/rfc/rfc2119.txtXBRLExtensible Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2005-11-07. Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis http://www.xbrl.org/SpecRecommendations/XLINKXML Linking Language (XLink) Version 1.0. Steve DeRose, Eve Maler, David Orchard http://www.w3.org/TR/xlink/

D Document Revision History (non-normative)

E Taxonomy Vernacular Examples

[insert example based on various industries or business data, table should contain concept name, at least on label (preferably standard and documentation) and comments as to how and why. It obviously must conform to the Style Guide]