Subsection Text Page

6.3.2

XBRL instance, schema, and linkbase documents must be attached to an EDGAR submission using the EX-100.*, EX-101.*, EX-99.K SDR.*, or EX-99.L SDR.* document types.

A single submission must not contain more than one of EX-100, EX-101, or EX-99.K SDR attachments. A submission may contain both EX-99.K SDR and EX-99.L SDR attachments.

All XBRL document types are listed in the table below.

XBRL
Document
XBRL
Related
Document
Types
Interactive
Data
Document
Types
Root
Element
Required
Element
Instance EX-100.INS EX-101.INS,
EX-99.K SDR.INS,
EX-99.L SDR.INS
xbrli:xbrl  
Schema EX-100.SCH EX-101.SCH,
EX-99.K SDR.SCH,
EX-99.L SDR.SCH
xsd:schema  
Calculation
Linkbase
EX-100.CAL EX-101.CAL,
EX-99.K SDR.CAL,
EX-99.L SDR.CAL
link:linkbase link:calculationLink
Definition
Linkbase
EX-100.PRE EX-101.PRE,
EX-99.K SDR.PRE,
EX-99.L SDR.PRE
link:linkbase link:definitionLink
Label
Linkbase
EX-100.LAB EX-101.LAB,
EX-99.K SDR.LAB,
EX-99.L SDR.LAB
link:linkbase link:labelLink
Presentation
Linkbase
EX-100.PRE EX-101.PRE,
EX-99.K SDR.PRE,
EX-99.L SDR.PRE
link:linkbase link:presentationLink
Reference
Linkbase
EX-100.REF EX-101.REF link:linkbase link:referenceLink

Note: Although the Reference Linkbase file is a valid attachment type, at the moment it is not used.

6-4

6.3.3

XBRL document names must match {base}-{date}[_{suffix}].{extension}.

XBRL Document Documentname Format
Instance {base}-{date}.xml
Schema {base}-{date}.xsd
Calculation Linkbase {base}-{date}_cal.xml
Definition Linkbase {base}-{date}_def.xml
Label Linkbase {base}-{date}_lab.xml
Presentation Linkbase {base}-{date}_pre.xml
Reference Linkbase {base}-{date}_ref.xml

Note: Although the Reference Linkbase file is a valid attachment type, at the moment it is not used.

The {base} should begin with the registrant’s ticker symbol or other mnemonic abbreviation.

The {date} must denote the ending date of the period. If the instance document is a prospectus or other report whose period is indefinite, {date} should match the filing date.

For example, a Form 10-Q covering the period ending September 30, 2009 has {date} = 20090930; and a 485BPOS filed on January 23, 2010 has {date} = 20100123.

The {base} should be the same as that used for the instance in the same submission. The {date} should be the same as that of the instance, even if the content of the schema is identical to some other schema, as for example if the same schema had been used in a previous quarterly filing.

The {base} and {date} should be the same as that used for the instance in the same submission.

6-5

6.3.4

An XBRL document must not contain HTML character name references.

Section 5.2.2.6 defines extended ASCII characters and how they may be referenced in HTML, but XBRL documents are not HTML documents, and recognize only XML predefined entities (" & ' < and >). To include characters greater than 127, use XML numeric character references. For example, ® and ® are ASCII sequences producing the ® symbol.

6-5

6.3.5

The ampersand character must begin a valid XML predefined entity or numeric character reference.

XML with invalid predefined entity or numeric character references are treated as if an invalid character had appeared. For example, &&; is invalid XML.

6-6

6.3.6

The URI content of the xlink:href attribute, the xsi:schemaLocation attribute and the schemaLocation attribute, must be relative and contain no forward slashes, or a recognized external location of a standard taxonomy schema file, or a "#" followed by a shorthand xpointer.

The xlink:href attribute must appear on the link:loc element; the schemaLocation attribute must appear on the xsd:import element, and the xsi:schemaLocation attribute must appear on the link:linkbase element and may appear on the xbrli:xbrl element.

Valid entries for the xlink:href attribute, the xsi:schemaLocation attribute and the schemaLocation attribute are document locations. If they are relative URIs, they are subject to EDGAR attachment naming conventions. Therefore, all documents attached to the submission will be at the same level of folder hierarchy. By restricting the content of these attributes, all documents in the DTS of an instance will be either a standard taxonomy or present in the submission.

Examples:

  • xlink:href="abccorp-20100123.xsd"
  • <xsd:import schemaLocation="http://xbrl.org/2006/xbrldi-2006.xsd" namespace="..."/>

Counterexamples:

  • xlink:href="http://www.example.com/2007/example.xsd"
  • xlink:href="#element(1/4)" (Comment: this is a scheme-based xpointer, not shorthand)

The XHTML namespace is intentionally omitted, since an XHTML declaration could not be a valid target for any XBRL element's xlink:href or schemaLocation attribute, and its presence in the xsi:schemaLocation attribute would not impact XBRL validation.

There are dozens of other XBRL US GAAP Taxonomies documents to be used as templates to copy from during the preparation process, but their inclusion in an EDGAR filing tends to load unused linkbases and therefore introduces unwarranted complications such as unused extended links and a need for many prohibiting arcs. Reducing the amount of content in the DTS of the instance to its essentials frees users to more easily link the submitted documents to the linkbases of their particular interest for analysis.

6-6

6.3.8

A submission must contain exactly one EX-100.INS or EX-101.INS or EX-99.K SDR.INS.

An XBRL instance submitted in the Voluntary Filing Program may be an EX-100.INS. An Interactive Data instance in XBRL format must be an EX-101.INS, EX-99.K SDR.INS, or EX 99.L SDR.INS.

6-6

6.3.11

Attribute xml:base must not appear in any Interactive Data document.

XML processors interpret this attribute differently, so it must not be used.

6-7

6.4.3

The XBRL instance documents in a submission must be XBRL 2.1 valid.

6-7

6.4.3

The XBRL instance documents in a submission must be XBRL 2.1 valid.

Constant Feature of Taxonomy Value
Dimensions 30
Defaults 30, so every dimension has one default
Line Items 1 abstract, 28 durations, 1 instant.
Constant Instance Feature Value
Periods 10, non overlapping.
Units Not applicable, all facts are Strings.
Parameterizable Instance Feature Value
Number of dimensions (axes) used in facts From 0 to 30
Possible non-default members per dimension (axis) From 1 to 29
Facts 5 DEI facts plus any number of dimensional facts, for example 10,000.
Dimensionally invalid facts Current generator only supports 0
Overlapping periods and instants Current generator only supports 0
Duplicate contexts Generator does not track, but variation does indicate whether they exist
6-8

6.5.1

The scheme attribute of the xbrli:identifier element must be http://www.sec.gov/CIK.

6-7

6.5.2

An xbrli:identifier element must have the CIK of the registrant as its content except in attachment EX 99.L SDR.INS when it contains the financial report of an entity without a CIK.

The CIK is an xsd:normalizedString of exactly ten digits from 0 to 9.

The xbrli:identifier contains the CIK of the registrant (issuer), not the filer. Fund Series and Class identifiers, which are nine digits following an S or C, are not allowed in the xbrli:identifier element. Document type EX-99.L SDR.INS may contain the financial report of an entity that is not an SEC registrant; in that case use 0000000000 in xbrli:identifier.

Each instance might have a different CIK for the value in the xbrli:identifier element. By contrast, if all subsidiaries are reported in the same instance, then the CIK of the holding company is the only CIK that will appear in the xbrli:identifier element of that one instance. Section 6.6 below contains rules that apply to the xbrli:context elements in an instance containing a combined submission.

6-97

6.5.3

All xbrli:identifier elements in an instance must have identical content.

.
6-8

6.5.4

The xbrli:scenario element must not appear in any xbrli:context.

If the xbrli:scenario element was used, then XBRL requires that it have child elements; however, all dimensions in Interactive Data filings appear in the xbrli:segment element. Therefore, the xbrli:scenario element cannot be used.

6-8

6.5.5

If an xbrli:segment element appears in a context, then its children must be one or more xbrldi:explicitMember elements.

The xbrldi:typedMember element cannot appear in an instance, nor can the xbrli:segment element be used for anything other than for explicit members.

6-8

6.5.7

An instance must not contain duplicate xbrli:context elements.

An instance must not contain equivalent xbrli:context elements. xbrli:segment elements are tested for equality of their children without regard to order. Contexts are defined to be equivalent if they have S-equal identifiers, equal dateUnion values for startDate, endDate and instant (respectively), and segment element children with equal QNames for each explicit dimension (the scenario element is disallowed by another rule).

The id attribute of an xbrli:context element can be any xsd:NCName, but users will find it helpful when it is a mnemonic string that contains the xbrli:period (or fiscal period), and the local part of the QName contents of the dimension attribute and xbrldi:explicitMember. There is usually no need to repeat the registrant name in the id attribute. There is no limit on the length of the id attribute.

The table shows examples of this usage.

Period xbrli:context id attribute
12 months of fiscal 2007 FY07d
End of fiscal 2007 FY07e
Start of fiscal 2007 FY06e
3 months of the 2nd Quarter of fiscal 2007 FY07Q2d
End of the 2nd Quarter of fiscal 2007 FY07Q2e
9 months year to date in fiscal 2007 FY07M9d
Fiscal 2006 previously reported amounts FY06d_ScenarioAxis_PreviouslyReportedMember
6-8

6.5.8

Every xbrli:context element must appear in at least one contextRef attribute in the same instance.

Unused xbrli:context elements have no benefit to users and are easily removed by the filer before submission.

6-8

6.5.9

If the duration of a context is more than 24 hours, then its endDate datetime value must not be greater than the startDate datetime of any other context by 24 hours or less.

Pairs of contexts must not overlap by 24 hours or less. Contexts of 24 hours or fewer are exempt from this constraint.

Note that XBRL 2.1 interprets a date used as a context start date as "midnight at the beginning of" that day.

For example, a company reporting at a May 31st, 2009 fiscal year-end will have contexts whose end date-time is midnight at the end of 2008-05-31 (the prior fiscal year) and contexts whose start date-times are midnight at the beginning of 2008-06-01 (the current fiscal year). It must not have any contexts with start date of midnight at the beginning of 2008-05-31, and no contexts with end date of midnight at the end of 2008-06-01.

6-9

6.5.11

Element xbrli:xbrl must not have duplicate child xbrli:unit elements.

Element xbrli:xbrl must not have equivalent child xbrli:unit elements. Units are equivalent if they have equivalent measures or equivalent numerator and denominator. Measures are equivalent if their contents are equivalent QNames. Numerators and Denominators are equivalent if they have a set of equivalent measures.

6-9

6.5.12

An instance must not have more than one fact having the same element name, equal contextRef attributes, and if they are present, equal unitRef attributes and xml:lang attributes, respectively, unless their fact values are the same.

An instance must not have more than one fact having S-Equal element names, equal contextRef attributes, and if they are present V-Equal unitRef attributes and xml:lang attribute effective values, respectively, unless their text content is V-Equal, in which case the distinct facts are consolidated into a single fact for all other validations. A fact is an occurrence in an instance of an element with a contextRef attribute. The values of the id attributes are not relevant to detection of duplicate facts. Other rules forbidding equivalent xbrli:context and xbrli:unit elements ensure that duplicate values of the contextRef and unitRef attributes can be detected without dereferencing.

The predicate V-Equal is defined in XBRL 2.1 section 1.4. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of '-6' is V-Equal to decimals '-06.0'. V-equal facts may have different specified or inferred decimals as defined in XBRL 2.1 section 4.6.6. For example, "123456 Shares with decimals equal to 'INF'" and "120000 Shares with decimals equal to '-3'" are V-equal. These facts are consolidated into a single fact having the maximum specified or inferred decimals value.

Calculation inconsistencies have no impact on the validity of EDGAR submissions, and therefore the effect of numeric fact duplication in XBRL 2.1 section 5.2.5.2 is moot.

6-9

6.5.13

The default value of the xml:lang attribute on non-numeric facts and on link:footnote is 'en-US'.

XBRL 2.1 does not specify a default value for the xml:lang attribute, but an Interactive Data instance assumes one.

6-10

6.5.14

An instance having a fact with non-nil content and the xml:lang attribute not equal to "en-US" must also contain a fact using the same element and all other attributes with an xml:lang attribute equal to "en-US".

Non-US English content may appear but it must be translated into US English.

For example, the US English fact below can appear in an instance without the French fact, but the French fact cannot appear without the US English fact:

<eg:q contextRef="x">yes</eg:q>
<eg:q contextRef="x" xml:lang="fr">oui</eg:q>
6-10

6.5.15

If the un-escaped content of a fact with base type us-types:textBlockItemType, or a type equal to or derived by restriction of type 'escapedItemType' in a standard taxonomy schema namespace contains the "<" character followed by a QName and whitespace, "/>" or ">", then the un-escaped content must contain only a sequence of text and XML nodes.

The "<" character may appear in the text content of an XML element as "&lt;", "&#x3C;", "&#60;" or some other guise; when it appears, the content of the element will then be "un-escaped" for analysis. If "<"is followed by a QName and whitespace, then the content is tested for XML well-formedness.

Although the name of every element in the US GAAP Taxonomies with base type us-gaap:textBlockItemType ends with the string "TextBlock," the reverse may not be true; an element name has no significance in this rule.

Some software applications may render the resulting content of the element as if it was embedded in an HTML 3.2 document, and well-formed XML is a prerequisite for well-formed HTML. Registrants may also choose other variations of HTML such as XHTML. Considering the status of the text as a kind of management assertion, well-formed XML is in the interest of the registrant because it decreases the likelihood of incorrect renderings.

HTML entity references such as &reg; must be doubly quoted as shown in the example above. Likewise, an XML entity reference such as & will appear in the un-escaped text only if double quoted.

6-10

6.5.16

Facts of type "text block" or a type (or derived by restriction from) the type 'escapedItemType' in a standard taxonomy schema namespace whose un-escaped content contains markup must satisfy the content model of the BODY tag as defined in 5.2.2.

This specifies the circumstances under which content containing escaped markup will be interpreted as HTML. HTML as accepted by EDGAR is detailed in section 5.2.2 and is based on HTML 3.2 elements and entities, with extensions (such as allowing the "style" attribute) and restrictions (such as disallowing the "SPAN" element).

Except for exceptions specified in 6.10, there is no prohibition on escaped markup appearing in other XBRL elements in schemas (such as link:definition) or linkbases (such as link:label), and the SEC Rendering does not unescape that content.

6-11

6.5.17

The xbrli:xbrl element must not have any facts with the precision attribute.

This applies to the submission only; the word "precision" may be used in other ways by XBRL preparation software.

6-11

6.5.19

An instance covering a reporting period must contain a Required Context that is an xbrli:context having xbrli:startDate equal to 00:00:00 on the first day of the reporting period and xbrli:endDate equal to 24:00:00 on its last day.

This rule defines "Required Context". For example, this rule applies to Form 10-Q filings for a company with a June 30, 2009 fiscal year end as follows:

Quarter xbrli:startDate xbrli:endDate
1 2009-07-01 2009-09-30
2 2009-07-01 2009-12-31
3 2009-07-01 2010-03-31

Many submissions require a second Required Context, see 6.5.21 below. Required contexts are distinguished by having no xbrli:segment elements.

Forms Shortest Typical
485BPOS, 497 P1D P1D
10-K, 10-K/A, 10-KT, F-1, F-3, F-4, F-9, F-10, S-1, S-3, S-4, S-11, N-CSR, N-CSR/A P1D P1Y
10-Q, 10-Q/A, 10-QT, N-Q P1D P9M
N-CSRS, N-CSRS/A P1D P6M
6-11

6.5.20

For each required Document Information element, an instance must contain a fact with that element and a contextRef attribute referring to its Required Context.

Required Document Information facts may specify attribute xml:lang, but facts with xml:lang attribute absent or xml:lang equal to "en-US" take precedence over facts with other languages starting with "en", which in turn take precedence over facts having other values for xml:lang. Additional facts using the Required Document Information elements are allowed in other contexts. The Required Document Information elements are:

Required Document Element Base Type (Example)
dei:DocumentType EDGAR Form Types
(Corporate Finance):
10, 10-K, 10-Q, 20-F, 40-F, 6-K, 8-K, F-1, F-10, F-3, F-4, F-9, S-1, S-11, S-3, S-4, POS AM , 10-KT, 10-QT, 10/A, 10-K/A, 10-Q/A, 20-F/A, 40-F/A, 6-K/A, 8-K/A, F-1/A, F-10/A, F-3/A, F-4/A, F-9/A, S-1/A, S-11/A, S-3/A, S-4/A, 10-KT/A, 10-QT/A

EDGAR Form Types
(Investment Management):
485BPOS, 497 , N-CSR, N-CSRS, N-Q, N-CSR-CSRS/A, N-Q

EDGAR Exhibit Types
(Trading & Markets):
K SDR, L SDR
8-K
485BPOS
dei:DocumentPeriodEndDate CCYY-MM-DD 2009-09-30
dei:AmendmentFlag xsd:Boolean true
dei:AmendmentDescription
(present if and only if dei:AmendmentFlag equals 'true')
xsd:normalizedString Correct the company HQ address

CCYY-MM-DD is an ISO 8601 format date. ISO 8601 is the international standard for representing dates, times, durations and periods issued by the International Standards Organization. Other elements in the "dei" namespace whose names start with "Document" are optional.

EDGAR
Submission Type:
DEI
DocumentType
Values:
"10-12B" "10-12B", "Other"
"10-12B/A" "10-12B/A", "Other"
"10-12G" "10-12G", "Other"
"10-12G/A" "10-12G/A", "Other"
"10-K" "10-K"
"10-K/A" "10-K", "10-K/A"
"10-KT" "10-KT", "10-K", "Other"
"10-KT/A" "10-KT/A", "10-K", "Other", "10-KT"
"10-Q" "10-Q"
"10-Q/A" "10-Q/A", "10-Q"
"10-QT" "10-QT", "10-Q", "Other"
"10-QT/A" "10-QT/A", "10-Q", "Other", "10-QT"
"20-F" "20-F"
"20-F/A" "20-F/A", "20-F"
"20FR12B" "20FR12B", "Other"
"20FR12B/A" "20FR12B/A", "Other"
"20FR12G" "20FR12G", "Other"
"20FR12G/A" "20FR12G/A", "Other"
"40-F" "40-F"
"40-F/A" "40-F/A", "40-F"
"40FR12B" "40FR12B", "Other"
"40FR12B/A" "40FR12B/A", "Other"
"40FR12G" "40FR12G", "Other"
"40FR12G/A" "40FR12G/A", "Other"
"485BPOS" "485BPOS"
"497" "497", "Other"
"6-K" "6-K"
"6-K/A" "6-K/A", "6-K"
"8-K" "8-K"
"8-K/A" "8-K/A", "8-K"
"8-K12B" "8-K12B", "Other"
"8-K12B/A" "8-K12B/A", "Other"
"8-K12G3" "8-K12G3", "Other"
"8-K12G3/A" "8-K12G3/A", "Other"
"8-K15D5" "8-K15D5", "Other"
"8-K15D5/A" "8-K15D5/A", "Other"
"F-1" "F-1"
"F-1/A" "F-1/A", "F-1"
"F-10" "F-10"
"F-10/A" "F-10/A", "F-10"
"F-10EF" "F-10EF", "Other"
"F-10POS" "F-10POS", "Other"
"F-1MEF" "F-1MEF"
"F-3" "F-3"
"F-3/A" "F-3/A", "F-3"
"F-3ASR" "F-3ASR", "F-3"
"F-3D" "F-3D", "F-3"
"F-3DPOS" "F-3DPOS", "F-3"
"F-3MEF" "F-3MEF"
"F-4" "F-4"
"F-4 POS" "F-4 POS", "F-4"
"F-4/A" "F-4/A", "F-4"
"F-4EF" "F-4EF", "F-4"
"F-4MEF" "F-4MEF"
"F-9" "F-9"
"F-9 POS" "F-9 POS", "F-9"
"F-9/A" "F-9/A", "F-9"
"F-9EF" "F-9EF", "F-9"
"N-1A" "N-1A"
"N-1A/A" "N-1A/A", "Other"
"N-CSR" "N-CSR"
"N-CSR/A" "N-CSR/A"
"N-CSRS" "N-CSRS"
"N-CSRS/A" "N-CSRS/A"
"N-Q" "N-Q"
"N-Q/A" "N-Q/A"
"POS AM" "F-1", "F-3", "F-4", "F-6", "S-1", "S-3", "S-4", "S-11", "S-20", "S-B", "POS AM", "Other"
"POS EX" "F-3", "F-4", "S-1", "S-3", "S-4", "POS EX", "Other"
"POS462B" "F-1MEF", "F-3MEF", "F-4MEF", "S-1MEF", "S-3MEF", "S-11MEF", "S-BMEF", "POS462B", "POS462C", "Other"
"POSASR" "F-3", "S-3", "POSASR", "Other"
"S-1" "S-1"
"S-1/A" "S-1/A", "S-1"
"S-1MEF" "S-1MEF"
"S-11" "S-11"
"S-11/A" "S-11/A"
"S-11MEF" "S-11MEF"
"S-3" "S-3"
"S-3/A" "S-3/A", "S-3"
"S-3ASR" "S-3ASR", "S-3"
"S-3D" "S-3D", "S-3"
"S-3DPOS" "S-3DPOS", "S-3"
"S-3MEF" "S-3MEF"
"S-4" "S-4"
"S-4 POS" "S-4 POS", "S-4"
"S-4/A" "S-4/A", "S-4"
"S-4EF" "S-4EF", "S-4"
"S-4MEF" "S-4MEF"
"SP 15D2" "SP 15D2"
"SP 15D2/A" "SP 15D2/A"
"SDR" "K SDR", "L SDR"
6-14

6.5.21

An instance must contain one non-empty fact for each required Entity Information element, each with a contextRef attribute referring to a Required Context. The value of an EntityPublicFloat fact in an instance will be 0 for an entity that has only public debt.

Required Entity Information facts may specify attribute xml:lang, but facts with xml:lang attribute absent or xml:lang equal to "en-US" take precedence over facts having other values for xml:lang.

Required Entity Information facts having period type "instant" use a context containing an xbrli:instant value that is the measurement date (for public float and common shares or other units of ownership outstanding), otherwise identical to the Required Context.

Additional facts using the Required Entity Information elements are allowed in other contexts.

The table below contains a description of the elements along with their base type, as well as providing an example for each.

Element Base Type (Example)
EntityRegistrantName xsd:normalizedString General Example Company
EntityCentralIndexKey us-types:centralIndexKey 0005551212
EntityCurrentReportingStatus us-types:yesNo Yes
EntityVoluntaryFilers us-types:yesNo No
CurrentFiscalYearEndDate xbrli:gMonthDayItemType --12-31 *
EntityFilerCategory us-types:filerCategory Large Accelerated Filer
EntityWellKnownSeasonedIssuer us-types:yesNo Yes
EntityPublicFloat xsd:decimal 987654321
DocumentFiscalYearFocus xbrli:gYearItemType 2009 **
DocumentFiscalPeriodFocus us-types:fiscalPeriodItemType FY, Q1, Q2, Q3, Q4, H1, H2, M9, T1, T2, T3, M8, CY

*Note: The value space of xbrli:gMonthDayItemType is in the format --MM-DD.

**Note: The value space of xsd:gYearItemType is a year in the form CCYY.

***Note: 10-Q‟s for the 1st, 2nd and 3rd quarters should have a fiscal period focus of Q1, Q2, and Q3 respectively, and a 10-K should have fiscal period focus of FY.

The following table shows which elements will be validated for each form type. Please note, however, that omitting the Registrant Name or Central Index Key leads to other errors, but otherwise, omission of data within the XBRL tags for these elements will not result in the suspension of the filing nor will the XBRL data be removed. Instead, a warning message will be added to the filer's acceptance message if the data is not included or does not match the base type as specified in the table above. All other Entity Information elements are optional (see 6.5.22).

Element 10-K,
10-KT
10-Q,
10-QT
20-F 40-F 6-K,
N-CSR,
N-Q,
N-CSRS
10, S-1,
S-3, S-4,
S-11,
POS AM
8-K, F-1,
F-3, F-10,
ARS,
485BPOS
EntityRegistrantName X X X X X X X
EntityCentralIndexKey X X X X X X X
EntityCurrentReportingStatus X X X
EntityVoluntaryFilers X
CurrentFiscalYearEndDate X X X X X
EntityFilerCategory X X X X
EntityWellKnownSeasonedIssuer X X
EntityPublicFloat X
DocumentFiscalYearFocus X X X X X
DocumentFiscalPeriodFocus X X X X X
6-14

6.5.22

All other elements in the dei namespace are optional.

6-14

6.5.23

The contents of the dei:EntityCentralIndexKey fact in the Required Context must equal the content of the xbrli:identifier element in that context.

6-14

6.5.24

The official Registrant Name that corresponds to the CIK of the xbrli:identifier text content must be a case-insensitive prefix of the dei:EntityRegistrantName fact in the Required Context, unless the xbrli:identifier value is 0000000000.

For example, the CIK 0005551212 has official registrant name ALPHA BETA CHI. The following would be valid values for dei:EntityRegistrantName: "alpha beta chi", "alpha beta chicago", "Alpha Beta Chicago", "aLpHa BeTa ChIcAgO". The following would not be valid: "alphabeta chi", "alpha beta", "alpha beta corp".

6-14

6.5.25

Elements with a type attribute having the local name 'domainItemType' in a standard taxonomy schema namespace, or a type derived by restriction from it, must not appear as facts in an instance.

Elements of this type are for use only in the xbrldi:explicitMember element.

6-14

6.5.26

An instance with dei:DocumentType of 10-K, 10-Q, 20-F, 40-F, 10-QT or 10-KT must have at least one dei:EntityCommonStockSharesOutstanding fact for each class of stock outstanding.

If an entity represented in the Required Context has only one class of common stock outstanding, then no matter what the share class is named, the instance requires only one dei:EntityCommonStockSharesOutstanding fact, and the context of that fact will have an xbrli:instant equal to the measurement date, and that context will have no xbrli:segment element.

If the entity represented in the Required Context has multiple classes of common shares outstanding, then the instance must not have any dei:EntityCommonStockSharesOutstanding fact in any context without an xbrli:segment. Instead, the instance must have a distinct context for each class of common stock outstanding, and each context will have xbrli:instant equal to the measurement date, an xbrli:segment with an explicit member of the us gaap:StatementClassOfStockAxis for each class of stock, and a dei:EntityCommonStockSharesOutstanding fact in each such context. This is a specific case of the more general requirement in 6.6.10 below.

[Variant] [Form Type] [Facts in Req Context] [Facts with Share Class] [Extra Facts] [Links] [Result]
000 10-K 0 0 0 true ng
001 10-K 0 0 1 true ng
002 10-K 0 1 0 true ng
003 10-K 0 1 1 true ng
004 10-K 0 2 0 true gd
005 10-K 0 2 1 true gd
006 10-K 1 0 0 true gd
007 10-K 1 0 1 true gd
008 10-K 1 1 0 true ng
009 10-K 1 1 1 true ng
010 10-K 1 2 0 true ng
011 10-K 1 2 1 true ng
012 10-Q 0 0 0 true ng
013 20-F 0 0 0 true ng
014 40-F 0 0 0 true ng
015 N-Q 0 0 0 true gd
016 8-K 0 0 0 true gd
017 6-K 0 0 0 true gd
018 N-CSR 0 0 0 true gd
019 485BPOS 0 0 0 true gd
020 Other 0 0 0 true gd
021 10-KT 0 0 0 true ng
022 10-KT 0 0 1 true ng
023 10-KT 0 1 0 true ng
024 10-KT 0 1 1 true ng
025 10-KT 0 2 0 true gd
026 10-KT 0 2 1 true gd
027 10-KT 1 0 0 true gd
028 10-KT 1 0 1 true gd
029 10-KT 1 1 0 true ng
030 10-KT 1 1 1 true ng
031 10-KT 1 2 0 true ng
032 10-KT 1 2 1 true ng
033 10-QT 0 0 0 true ng
034 10-K 0 0 0 false ng
035 10-K 0 0 1 false ng
036 10-K 0 1 0 false ng
037 10-K 0 1 1 false ng
038 10-K 0 2 0 false gd
039 10-K 0 2 1 false gd
040 10-K 1 0 0 false gd
041 10-K 1 0 1 false gd
042 10-K 1 1 0 false ng
043 10-K 1 1 1 false ng
044 10-K 1 2 0 false ng
045 10-K 1 2 1 false ng
046 10-Q 0 0 0 false ng
047 20-F 0 0 0 false ng
048 40-F 0 0 0 false ng
049 N-Q 0 0 0 false gd
050 8-K 0 0 0 false gd
051 6-K 0 0 0 false gd
052 N-CSR 0 0 0 false gd
053 485BPOS 0 0 0 false gd
054 Other 0 0 0 false gd
055 10-KT 0 0 0 false ng
056 10-KT 0 0 1 false ng
057 10-KT 0 1 0 false ng
058 10-KT 0 1 1 false ng
059 10-KT 0 2 0 false gd
060 10-KT 0 2 1 false gd
061 10-KT 1 0 0 false gd
062 10-KT 1 0 1 false gd
063 10-KT 1 1 0 false ng
064 10-KT 1 1 1 false ng
065 10-KT 1 2 0 false ng
066 10-KT 1 2 1 false ng
067 10-QT 0 0 0 false ng
6-16

6.5.27

A link:footnoteLink element must have no children other than link:loc, link:footnote, and link:footnoteArc.

Although valid XBRL 2.1, custom elements in the substitution groups of link:loc, link:footnote or link:footnoteArc have no value to users.

6-15

6.5.28

The xlink:role attribute of a link:footnote element must be defined in the XBRL Specification 2.1.

6-15

6.5.29

The xlink:role attribute of a link:loc element must be empty, or defined in the XBRL Specification 2.1.

6-15

6.5.32

A link:footnoteLink link:loc xlink:href attribute must start with the sharp sign "#".

Occurrences of link:footnote in an instance can only refer to facts in that instance. The target of a link:footnote locator xlink:href attribute may be an element with xsi:nil='true', so registrants should not assume that a "nil" fact is completely equivalent to a "missing" fact.

6-15

6.5.33

Every nonempty link:footnote element must be linked to at least one fact.

A nonempty link:footnote element must have an xlink:label attribute equal to an xlink:to attribute of a sibling link:footnoteArc.

Footnotes with text must not "dangle". By contrast, a link:loc element that is not connected by a link:footnoteArc is legal syntax.

6-15

6.5.34

The content of a link:footnote element must satisfy the content model of the BODY tag as defined in 5.2.2.

XBRL 2.1 allows link:footnote elements to contain XHTML. HTML as accepted by EDGAR is detailed in section 5.2.2 and is based on HTML 3.2 elements and entities, with extensions (such as allowing the "style" attribute) and restrictions (such as disallowing the "SPAN" element.

6-16

6.5.35

If element "UTR" in a standard namespace is declared in the DTS of an instance, then the value of each 'unitRef' attribute on each fact of a type in that registry must refer to a unit declaration consistent with the data type of that fact, where consistency is defined by that registry.

XBRL 2.1 already enforces the requirement that a fact of type xbrli:monetaryItemType must have a unitRef whose xbrli:measure is an ISO standard currency. A standard numeric data type registry is similar but broader: it has a schema with numeric type declarations, and each numeric data type is associated with consistent unit declaration measures, numerators and denominators.

A portion of a registry is shown below; additional information is at http://www.sec.gov/edgar/info/edgartaxonomies.shtml.

Type name-space Type element name Unit measure name-space Unit measure element names Meaning Unit numerator name-space Unit numerator element name Unit denominator namespace Unit denominator element name
(any) percentItemType xbrli pure   n/a disallowed n/a disallowed
(any) perShareItemType n/a disallowed   iso4217 3-letter ISO 4217 codes xbrli shares
(any) areaItemType (any) sqft Square Foot n/a disallowed n/a disallowed
sqyd Square Yard
sqmi Square Mile
A Acre
sqm Square Meter
sqkm Square Km
sqemi Square English Mile
(any) volumeItemType (any) l Liter n/a disallowed n/a disallowed
m3 Cubic Meter
ft3 Cubic Foot
gal Gallon
cf Cubic Feet of Natural Gas at 14.73psi and 60 degrees F
Mcf Thousands of Cubic Feet of Natural Gas at 14.73psi and 60 degrees F
MMcf Millions of Cubic Feet of Natural Gas at 14.73psi and 60 degrees F
bbl Barrels of Oil at 60 degrees F
MBbls Thousands of Barrels of Oil at 60 degrees F
MMbbls Millions of Barrels of Oil at 60 degrees F

In this table, for example, facts whose type is based on areaItemType must have a unit whose measure is one of sqft, sqyd, sqmi, etc. The notation "(any)" means that the element namespace is ignored for the purposes of checking for consistency.

6-16

6.5.36

The local name part of the content of xbrli:measure in UTF-8 must not exceed 200 bytes in length.

This length restriction applies to bytes in UTF-8 encoding, not characters. See 6.7.29 below.

6-16

6.5.37

The decimals attribute value must not cause non-zero digits in the fact value to be interpreted as zero.

If the decimals attribute of a numeric fact is not equal to 'INF', then the value is interpreted as if certain digits were zero. Interactive Data documents must not contain usage that results in such truncations. The examples below illustrate correct and incorrect use:

Fact text Decimals value Interpreted value Result
-2345.67 INF -2,345.67
-2345.67 2 -2,345.67
-2345.67 0 -2,345.00 Error
-2345.67 -2 -2,300.00 Error
-2345.67 -3 -2000.00 Error
-2345.67 -6 0000.00 Error

For further information and guidance using the decimals attribute, see 6.6.32 below.

6-17

6.5.38

Do not use the forever period in contexts.

6-17

6.7.1

The xsd:schema must not have an xsd:include element.

This rule does not apply to schemas in a standard taxonomy.

There is one namespace per xsd:schema element and therefore no "chameleon schemas", and additional XBRL 2.1 syntax restrictions apply.

The elementFormDefault attribute is usually "qualified" and the attributeFormDefault attribute usually "unqualified", but there are no formal restrictions on the values of these attributes and no formal restrictions on the formDefault attribute.

6-30

6.7.3

The authority part of a xsd:schema targetNamespace attribute must not equal the authority part of a targetNamespace attribute of any standard taxonomy schema.

6-33

6.7.4

The targetNamespace attribute must match http://{authority}/{versionDate}.

The company-specific schema has a unique targetNamespace attribute name for each schema. Namespaces are not to be confused with external references even though they may appear to have very similar formats. An external reference describes the location of a particular file with the intent of accessing the contents of that file. A namespace, on the other hand, is a name that identifies elements that belong to a particular markup vocabulary. However, since they function very differently, restrictions that are placed on external references do not apply to namespaces. Since a particular instance document is expected to reference multiple vocabularies, namespaces provide a convention by which each vocabulary is uniquely identified. This avoids problems of recognition and collision of similarly named elements from different vocabularies appearing in XBRL documents.

6-32

6.7.6

The targetNamespace attribute must be a valid URI with a {versionDate} that identifies the release date of the schema.

Examples:

  • http://abcinc.com/20080331, http://www.definc.us/20081231

Counterexamples:

  • http://sec.gov/abc/20080331, http://abcinc.com/2009

The targetNamespace attribute of the schema is different than the scheme attribute in the xbrli:identifier element; the scheme attribute refers to the SEC and the targetNamespace attribute does not.

6-31

6.7.7

Element xsd:schema must bind a Recommended Namespace Prefix for the targetNamespace attribute that does not contain the underscore character.

6-31

6.7.8

Element xsd:schema must not contain any occurrences of "embedded" linkbases.

6-31

6.7.9

The roleURI attribute of a link:roleType element must begin with the same {scheme} and {authority} as the targetNamespace attribute.

For example, in an xsd:schema with a targetNamespace attribute equal to 'http://abcinc.com/2009-02-29', the string 'http://abcinc.com/' must start the roleURI attribute value of any link:roleType.

The roleURI attribute should be considered permanent, to be used in future submissions.

In a link:roleType declaration the roleURI attribute should end with "/role/" and a mnemonic name in LC3 format.

For example,

<link:roleType @roleURI="http://abcinc.com/role/StatementOfIncome"> ...</link:roleType>

6-32

6.7.10

A DTS must not contain more than one link:roleType element with equal values of the roleURI attribute.

6-32

6.7.11

A link:roleType declaration with link:usedOn containing link:presentationLink, link:definitionLink or link:calculationLink must also have a link:usedOn for the other two.

This rule is relevant to three of the linkbase elements whose type attribute is fixed at 'extended' as shown in the table below.

type attribute QName in link:usedOn Declared by
extended link:calculationLink link:roleType
extended link:definitionLink link:roleType
extended link:presentationLink link:roleType
6-32

6.7.12

A link:roleType element must contain a link:definition child element whose content will communicate the title of the financial statement section, the level of facts in the instance that a presentation relationship in the base set of that role would display, and sort alphanumerically into the order that statements and footnotes appear in the official HTML/ASCII document.

The link:roleType link:definition text must match the following pattern:

{SortCode} - {Type} - {Title}

The {Type} must be one of the words 'Disclosure', 'Document', 'Schedule' or 'Statement'.

The meaning of the base set appears in {Title}.

{SortCode} is used only to sort base sets for display. The sort code is sorted alphanumerically, not numerically, so "10" would appear before "2". Filers must choose a scheme for their sort code and declare separate role types so as to achieve the following:

  1. Each Statement must appear in at least one base set, in the order the statement appeared in the official HTML/ASCII document.
  2. If the presentation relationships of more than one base set contains the facts of a Statement (to achieve a layout effect, such as a set of rows, followed by a table with a dimension axis on the vertical, followed by another set of rows) then the {SortCode} of that base set must sort in the order that the rows of the Statement will be displayed.
  3. A Statement that contains parenthetical disclosures on one or more rows must have a base set immediately following that of the Statement, where all facts in its parenthetical disclosures appear in presentation relationships.
  4. All base sets containing the contents of Footnotes must appear after base sets containing the contents of Statements.
  5. A Text Block for each Footnote must appear in at least one presentation relationship in a base set.
  6. Each base set for a "Footnote as a Text Block" presentation link must contain one presentation relationship whose target is a Text Block.
  7. Base sets with presentation relationships for a Footnote tagged at level (ii) must appear after all base sets tagged at level (i).
  8. A base set with presentation relationships for a Footnote tagged at level (iii) must appear after all base sets tagged at level (ii).
  9. A base set with presentation relationships for a Footnote tagged at level (iv) must appear after all base sets tagged at level (iii).

The {Title} is the text that follows " - " in the link:definition. The text should distinguish to a human reader what each separate relationship group contains. The table below shows an example in which the filer has simply used a two-digit sequence number.

The {Title} must not contain scale or units (such as "in millions of US dollars except per share data") text.

Note: the link:definition MUST NOT have leading or trailing XML whitespace.

Example link:definition Text Each Footnote as a Text Block Each Accounting Policy as a Text Block Each Table in a Footnote as a Text Block Individual Values or Narratives
01 - Statement - Statement of Income Yes
02 - Statement - Balance Sheet Yes
03 - Statement - Balance Sheet (Parenthetical) Yes
04 - Statement - Cash Flows Yes
05 - Statement - Changes in Equity Yes
06 - Statement - Comprehensive Income Yes
07 - Disclosure - Accounting Policies Yes
08 - Disclosure - Inventories Yes
09 - Disclosure - Earnings per Share Yes
10 - Disclosure - Unearned Revenue Yes
11 - Disclosure - Equity Yes
12 - Disclosure - Accounting Policies, by Policy Yes
13 - Disclosure - Inventories (Tables) Yes
14 - Disclosure - Unearned Revenue (Tables) Yes
15 - Disclosure - Equity, Share Repurchases (Table) Yes
16 - Disclosure - Equity, Dividends (Table) Yes
17 - Disclosure - Inventories (Detail) Yes
18 - Disclosure - Unearned, by Component (Detail) Yes
19 - Disclosure - Unearned, by Segment (Detail) Yes
20 - Disclosure - Equity, Share Repurchases (Detail) Yes
21 - Disclosure - Equity, Dividends (Detail) Yes

Defining roles is important, because the SEC Interactive Data Viewer displays all the facts in an instance if they appear in a presentation relationship, and displays facts only when they appear in a presentation relationshiparc in a base set of the role. Note that if the link:definition text matches "{SortCode} - {Type} - {Title}" then the SEC Interactive Data Viewer shows only the {Title} part.

6-36

6.7.13

The arcroleURI attribute of a link:arcroleType element must begin with the same {scheme} and {authority} parts as the targetNamespace attribute.

6-34

6.7.14

A DTS must not contain more than one link:arcroleType element with equal values of the arcroleURI attribute.

6-34

6.7.15

A link:arcroleType element must have a nonempty link:definition.

The link:arcroleType link:definition text should explain the purpose of the arc role.

The content of link:usedOn is the QName of an arc element; however, note that there are additional rules that restrict what may be used as the value of the xlink:arcrole attribute in instances, schemas and linkbases.

6-34

6.7.16

The name attribute of an xsd:element must not equal any xsd:element name attribute in a standard taxonomy.

It is not necessary to compare the @name attribute to all element declarations in all standard taxonomy schemas. Only those schemas that are present in the DTS of a specific instance being validated are relevant.

6-35

6.7.17

The id attribute of an xsd:element must consist of the Recommended Namespace Prefix of the element namespace, followed by one underscore, followed by its name attribute.

6-35

6.7.18

The nillable attribute value of an xsd:element must equal "true".

6-35

6.7.19

The xsd:element substitutionGroup attribute must not be a member of a substitution group with head 'xbrli:tuple'.

6-35

6.7.20

An xsd:element must not have an xbrldt:typedDomainRef attribute.

6-35

6.7.21

If the abstract attribute of xsd:element is 'true', then the xbrli:periodType attribute must be 'duration'.

6-35

6.7.23

The xsd:element substitutionGroup attribute must equal 'xbrldt:dimensionItem' if and only if the name attribute ends with 'Axis'.

6-35

6.7.24

The xsd:element name attribute must end with 'Table' if and only if substitutionGroup attribute equals 'xbrldt:hypercubeItem'.

An element is defined to be a "Table" if and only if its substitutionGroup attribute equals 'xbrldt:hypercubeItem'.

6-35

6.7.25

If the xsd:element substitutionGroup attribute is not equal to 'xbrldt:dimensionItem' or equal to 'xbrldt:hypercubeItem' then it must equal 'xbrli:item'.

6-35

6.7.26

If xsd:element name attribute ends with 'LineItems' then the abstract attribute must equal 'true'.

6-35

6.7.27

The xsd:element name attribute must end with 'Domain' or 'Member' if and only if the type equals or is derived from 'domainItemType' in a standard taxonomy schema target namespace.

A "domain member" is defined as an element meeting this condition.

6-36

6.7.28

If xsd:element type attribute equals or is derived from 'domainItemType' in a standard taxonomy schema target namespace then the xbrli:periodType attribute must equal 'duration'.

6-36

6.7.29

The content of an xsd:element, xsd:complexType, or xsd:simpleType name attribute in UTF-8 must not exceed 200 bytes in length.

This length restriction applies to bytes in UTF-8 encoding, not characters. For example, an element name of 101 repetitions of character "Ā" (Unicode x0100) violates this criterion because its UTF-8 encoding has 202 bytes.

By contrast, the six-byte EDGAR accepted encoding of that same character, "&#256;" when read and stored as an XML text node in UTF-8 encoding, would be only two bytes. Therefore up to 100 repetitions of that sequence would be allowed.

Names of reasonable length limited to US ASCII characters avoid such complexities entirely and are advisable.

6-38

6.7.30

The content of a targetnamespace, roleURI or arcroleURI attribute in UTF 8 must not exceed 255 bytes in length.

This length restriction applies to bytes in UTF-8 encoding, not characters. See 6.7.29 above.

6-38

6.7.31

The xsd:element type must not be equal to or derived from xbrli:fractionItemType.

6-36

6.7.32

An element declaration having a non-numeric base type, abstract not 'true', and not derived from domainItemType must have the value 'duration' for xbrli:periodType.

In combination with 6.7.21 and 6.7.28 this means that only element declarations having a numeric base type may have period type 'instant'.

6-36

6.9.3

A link:linkbase in a submission must have no ineffectual arcs.

Elements of the xlink:type="arc" attribute are ineffectual when there is an equivalent arc with the same or higher priority. An arc with use="prohibited" always takes precedence over arcs with use="optional" when their priorities are the same.

Examples:

  • An arc with a use attribute equal to 'prohibited' with no equivalent arc is ineffectual.
  • An arc with a use attribute equal to 'prohibited' with the priority attribute less than the priority attribute of an effective arc is ineffectual.
  • An arc in a submission may cause an arc in a standard taxonomy to become ineffective.

Elements of the xlink:type="arc" attribute are ineffectual when there is an equivalent arc with the same or higher priority or when it overrides an unprohibited arc. An arc with use="prohibited" always takes precedence over arcs with use="optional" when their priorities are the same.

Examples:

  • An arc with use="prohibited" in a submission may prohibit an arc in a standard taxonomy.
  • An arc with use="prohibited" with no equivalent arc is ineffectual.
  • An arc with use="prohibited" with the priority attribute less than the priority attribute of an effective arc is ineffectual.
  • An arc with use="optional" in a submission that is prohibited is ineffectual.
  • An arc with use="optional" in a submission may not be equivalent to an unprohibited arc in a standard taxonomy.
6-42

6.9.4

The xlink:role attribute of an element with a type='extended' attribute or a type='resource' attribute must be present and must not be empty.

6-43

6.9.5

The xlink:role attribute of an element with an xlink:type attribute of 'resource' must be present and must be defined in XBRL 2.1 or a standard taxonomy.

6-43

6.9.6

The text preceding a sharp sign '#' in an xlink:href attribute of link:arcroleRef must be a standard taxonomy.

No custom arc roles.

6-43

6.9.7

All extended link elements in a single linkbase must have the same namespace and local name.

An element is an extended link if its type attribute is equal to 'extended'.

A single linkbase cannot mix different kinds of link elements.

6-43

6.9.9

The value of the priority attribute must be strictly less than 10.

Future standard taxonomy linkbases may need to prevent specific arcs from being prohibited.

6-43

6.10.1

An element used in a fact or xbrldi:explicitMember in an instance must have an English standard label in the DTS of that instance.

An element "has an English standard label" in a DTS if there is an effective arc with the defining xsd:element source, an xlink:arcrole attribute equal to 'http://www.xbrl.org/2003/role/concept-label' and target link:label with an xml:lang attribute equal to 'en-US' and an xlink:role attribute equal to 'http://www.xbrl.org/2003/role/label'.

This rule is particularly relevant to elements declared in the company schema, because a document that could contain a link:label for a company-specific element would never appear in a standard taxonomy, and therefore has to be in a label linkbase in the same submission. It is not necessary for the DTS to have a standard label for all elements declared in the DTS.

6-43

6.10.2

An element used in a fact or xbrldi:explicitMember in an instance must have at most one label for any combination of the xlink:role attribute and the xml:lang attribute in the DTS of that instance.

An element "has a label" in a DTS if there is an effective arc with the defining xsd:element source, an xlink:arcrole attribute equal to 'http://www.xbrl.org/2003/role/label' and target link:label with an xml:lang attribute starting with 'en'.

This rule is particularly relevant to elements declared in the company schema, because a document that could contain a link:label for a company-specific element would never appear in a standard taxonomy, and therefore has to be in a label linkbase in the same submission.

6-44

6.10.3

If an element used in an instance is assigned a label in the DTS whose xml:lang attribute does not equal 'en-US', then the DTS must also contain a link:label for the same element and all other attributes with an xml:lang attribute equal to 'en-US'.

Non-US English labels may appear for elements in the schema, but they must be translated into US English if they are used in an instance.

6-44

6.10.4

The DTS of an instance must have no distinct elements having the same English standard label (xml:lang attribute equal to "en-US").

Users will most often see the English standard label of a concept, and it decreases clarity if distinct elements have the same label. Note that there is no restriction on elements having duplicated labels for other values of an xlink:role attribute.

6-44

6.10.5

A label linkbase must not have a definition for an element defined in a standard taxonomy.

The rule prevents an extension linkbase from removing the documentation from a published element. This is important for comparability and to prevent contradictory definitions for elements.

6-44

6.10.6

The ASCII text of link:label must be a string of fewer than 511 characters with no consecutive XML whitespace characters and no occurrences of '<' unless its xlink:role attribute is 'http://www.xbrl.org/2003/label/documentation'.

ASCII character 60 (decimal) and the following ASCII sequences are prohibited in the content of labels other than documentation labels: &lt; &#60; &#x3C.

6-44

6.10.8

The text of link:label must not have leading or trailing XML whitespace.

All labels may contain the XML whitespace characters ASCII 9, 10, 13 and 32 anywhere except at their start or end. Documentation labels may contain sequences of extra whitespace; all other labels must be normalized; see 6.10.6.

6-46

6.10.9

Non-numeric elements must not have labels whose xlink:role value implies they apply to numeric values.

Value of the xlink:role attribute on link:label Non numeric?
http://www.xbrl.org/2003/role/totalLabel Disallowed
http://www.xbrl.org/2003/role/positiveLabel
http://www.xbrl.org/2003/role/negativeLabel
http://www.xbrl.org/2003/role/zeroLabel
http://www.xbrl.org/2003/role/positiveTerseLabel
http://www.xbrl.org/2003/role/negativeTerseLabel
http://www.xbrl.org/2003/role/zeroTerseLabel
http://www.xbrl.org/2003/role/positiveVerboseLabel
http://www.xbrl.org/2003/role/negativeVerboseLabel
http://www.xbrl.org/2003/role/zeroVerboseLabel
http://www.xbrl.org/2009/role/negatedLabel
http://www.xbrl.org/2009/role/negatedPeriodEndLabel
http://www.xbrl.org/2009/role/negatedPeriodStartLabel
http://www.xbrl.org/2009/role/negatedTotalLabel
http://www.xbrl.org/2009/role/negatedNetLabel
http://www.xbrl.org/2009/role/negatedTerseLabel
All Others Allowed
6-46

6.12.1

The link:presentationArc element requires an order attribute.

6-51

6.12.2

All effective presentation relatonships in the same base set with the same source element must have distinct values of the order attribute.

This rule ensures an intentional ordering of facts when displayed.

6-51

6.12.3

An element used in an instance must participate in at least one effective presentation relationship in the DTS of that instance.

An element "participates in" a presentation arc in a DTS if it is a source or target of a presentation relationship in that DTS.

An element is "a source of a presentation relationship" in a DTS if there is an effective arc with the defining xsd:element source and an xlink:arcrole attribute equal to 'http://www.xbrl.org/2003/role/parent-child' in a document of that DTS.

An element is "a target of a presentation relationship" in a DTS if there is an effective arc with the defining xsd:element target and an xlink:arcrole attribute equal to 'http://www.xbrl.org/2003/role/parent-child' in a document of that DTS.

Every fact must be displayable in some way using presentation relationships. This rule is relevant to all elements but particularly so to elements declared in the company schema, because a linkbase that could contain a link:loc element for a company-specific element would never appear in a standard taxonomy, and therefore has to be in a linkbase in the same submission.

Elements used in an instance only as QNames in xbrldi:explicitMember must nevertheless have a presentation relationship in the DTS of that instance.

It is not necessary for the DTS to have a presentation relationship for all elements declared in the DTS.

6-51

6.12.5

If an element used in an instance is the target in the instance DTS of more than one effective presentation relationship in a base set with the same source element, then the presentation relationships must have distinct values of the preferredLabel attribute.

This rule prevents the same fact from appearing twice in a set of line items, except when it is, for example, shown as both the beginning and ending value of a roll forward.

6-52

6.12.5

Each presentation base set should have only one root element.

An element that appears in a presentation base set only as a source and never as a target is a root element of that base set.

6-52

6.12.5

A presentation relationship whose target is an xsd:element with an xbrli:periodType attribute equal to 'duration' should not have a preferredLabel attribute value that is a role for elements with xbrli:periodType attribute equal to 'instant'.

An element that appears in a presentation base set only as a source and never as a target is a root element of that base set. A "duration-type element" is an element with xbrli:periodType equal to "duration". An "instant-type element" is an element with xbrli:periodType equal to "instant". Roles that contain the text "periodStart," "periodEnd", "PeriodStart", or "PeriodEnd" anywhere in the role URI should not be used as the preferred label of an instant-type element.

6-52

6.12.5

Each axis element in a presentation base set should be the source of at least one presentation relationship whose target is a domainItemType element.

As detailed in section 6.24, an axis element appearing in a presentation base set without any child elements will filter out all facts and prevent the entire base set from being used for presentation.

6-52

6.12.5

A presentation base set having a relationship whose target has the same local name as the unitRef attribute value of a fact of an element the presentation base set contains should provide an ordering for all unitRef attribute values on all elements it contains.

As detailed in 6.24, the renderer displays sets of facts having multiple units of measure using a unit axis ordered by relationships in a presentation base set, or by the order of appearance of units in the instance. The presentation base set should either order all the units used, or none of them, so that the ordering is not mixed.

6-52

6.14.1

Element link:calculationArc requires an order attribute.

6-53

6.14.2

Element link:calculationArc requires a weight attribute value equal to 1 or -1.

6-53

6.14.3

The source and target of an effective calculation arc must have equal values of the xblri:periodType attribute.

Facts of elements with different values of the xbrli:periodType attribute must have different values of the contextRef attribute and therefore the calculation arc between them has no meaning.

6-53

6.14.4

There must be no directed cycles in effective relationships having arc role http://www.xbrl.org/2003/role/summation-item.

This rule prevents a fact from participating in a summation that includes itself.

6-54

6.14.5

If an instance contains non-empty facts for the source and target of an effective calculation relationship, then at least one effective presentation relationship that the source and target appear in (because of 6.12.3) must be either (a) a relationship with each other or (b) two relationships with any other elements that share a single extended link role.

When facts participate in a calculation together, they must be shown with presentation relationships in the same relationship group, although not necessarily adjacent to each other.

6-54

6.16.1

Element link:definitionArc requires an order attribute.

This ensures an intentional displayed order of definition relationships.

6-56

6.16.3

The target of an effective relationship with an xlink:arcrole attribute equal to 'http://xbrl.org/int/dim/arcrole/dimension-domain' or 'http://xbrl.org/int/arcrole/dimension-default' must be a domain or member.

In this rule both the dimension-domain and the dimension-default arc roles must have a source that is an Axis (xbrldt:dimensionItem); these two rules work together to ensure that each Axis has an meaningful set of domain members.

6-56

6.16.4

The xlink:arcrole attributes 'http://xbrl.org/int/dim/arcrole/domain-member' and 'http://xbrl.org/int/dim/arcrole/dimension-domain' must have no undirected cycles in any Directed Relationship Set as defined in XBRL Dimensions 1.0.

For example, company ABC defines, in us-gaap:SegmentGeographicalDomain, the regions abc:MidwestMember and abc:SoutheastMember, but stpr:KY (Kentucky) cannot be in both regions.

This rule also impacts line items, so that the balance at the start and end a roll forward cannot appear twice under a single axis. The same rendering effect is achieved by including only the ending balance in the domain-member relationships, so that the beginning balance will appear simply as the ending balance of the previous period.

Tables define the rows and columns (the axes) that cells (the facts) may have. The domain-member arc role defines relationships within each row or column, such as those between a parent entity and its reportable segments, among sets of classes of equity, and or among geographical regions. Tables become difficult to consistently populate with facts and ambiguous to display when elements can appear in more than one domain member. This rule ensures that any given element does not appear in more than one place along an Axis, and will not have any overlapping domain subsets or members. In general, almost every situation that at first appears to call for an Axis with tangled and overlapping subsets of Member elements actually turns out to be a case more clearly modeled using two distinct axes.

6-56

6.16.5

The DTS of an instance must contain in each base set, for each source element, at most one effective relationship with an xlink:arcrole attribute equal to 'http://xbrl.org/int/dim/arcrole/all'.

A fact can always appear in more than one Table (hypercube), but this rule prevents a fact from having contradictory meanings in different Tables.

6-56

6.16.6

An effective relationship with an xlink:arcrole attribute equal to 'http://xbrl.org/int/dim/arcrole/notAll' must have an xbrldt:closed attribute equal to 'false'.

A closed negative hypercube is better modeled with an open positive hypercube.

6-57

6.16.7

An axis of a negative table must appear in a positive table in a definitionLink having an equal value of xlink:role.

An Axis cannot appear as an Axis of a negative hypercube (that is, axis excluded from a table) unless there are members of that Axis in a positive table.

Formally, an axis element that is the target of an effective relationship with arcrole equal to 'http://xbrl.org/int/dim/arcrole/hypercube-dimension' that is consecutive from a relationship with arc role 'http://xbrl.org/int/dim/arcrole/notAll' must also be the target of an effective relationship in a link:definitionLink having the same value of xlink:role, and which itself is consecutive from an effective relationship with xlink:arcrole attribute equal to 'http://xbrl.org/int/dim/arcrole/all'.

An instance DTS in which the arc role 'http://xbrl.org/int/dim/arcrole/notAll' does not appear will not be affected by this rule.

6-57

6.16.8

The target of an effective relationship with an xlink:arcrole attribute equal to 'http://xbrl.org/int/dim/arcrole/notAll' must not be the target of an effective arc with an xlink:arcrole attribute equal to 'http://xbrl.org/int/dim/arcrole/all' in link:definitionLink elements having the equal values of xlink:role.

This rule ensures that a Table (hypercube) is not both positive and negative.

6-57

6.16.9

If the value of attribute xbrldt:targetRole on an effective definition relationship is not empty, then it must have at least one effective consecutive relationship, as defined by the XBRL Dimensions specification.

The xbrldt:targetRole attribute is used to connect certain definition arcs that appear in different extended link roles. A targetRole attribute that points to no arcs indicates that a table is malformed.

6-57

6.18.1

An element that has a company specific namespace must not have a reference.

The elements defined in a company extension schema must not have any authoritative references.

An xsd:element "has a reference" if the DTS of the instance contains an effective reference arc whose source is that xsd:element. A reference linkbase should only be attached to a submission when it is a copy of a linkbase published along with a schema for early adopters. In that situation the schema would have a targetNamespace attribute of some authority other than the registrant itself.

6-58

6.18.2

A company extension reference linkbase must not add, remove or change references for any element declared in a standard taxonomy schema.

6-58

6.22.1

Supported Versions of XBRL Standard Taxonomies.

Refer to the SEC's public website ( http://www.sec.gov/info/edgar/edgartaxonomies.shtml) for an up-to-date listing of standard taxonomy files that are supported by EDGAR, their locations, required namespaces, and where appropriate, the relevant EDGAR form types.

6-55
6-59

6.22.2

Supported Versions of XBRL Standard Taxonomies.

Refer to the SEC's public website ( http://www.sec.gov/info/edgar/edgartaxonomies.shtml) for an up-to-date listing of standard taxonomy files that are supported by EDGAR, their locations, required namespaces, and where appropriate, the relevant EDGAR form types.

6-59

6.22.3

Supported Versions of XBRL Standard Taxonomies.

Refer to the SEC's public website ( http://www.sec.gov/info/edgar/edgartaxonomies.shtml) for an up-to-date listing of standard taxonomy files that are supported by EDGAR, their locations, required namespaces, and where appropriate, the relevant EDGAR form types.

6-59

6.22.4

Supported Versions of XBRL Standard Taxonomies.

Refer to the SEC's public website ( http://www.sec.gov/info/edgar/edgartaxonomies.shtml) for an up-to-date listing of standard taxonomy files that are supported by EDGAR, their locations, required namespaces, and where appropriate, the relevant EDGAR form types.

6-55

6.26.1

If a presentation base set contains an axis element but not the default member of that axis, this should not result in an empty set of facts displayed.

If the default member of an axis does not appear in a presentation base set, then the only facts that can be displayed by that presentation base set are facts in contexts having a non-default member on that axis. If the instance contains no such facts, then the presentation base set will never display anything.

6-00

6.26.2

Facts presented in a presentation base set using period start or period end preferred labels should contain alternating instants and durations.

The renderer lays out a set of facts with at least one column for each period, ordering the columns by increasing duration and descending date.

A presentation group in which facts are presented with the period start and period end roles as described in 6.12.6 is considered a movement analysis. When the renderer presents a movement analysis of a set of facts consisting of beginning and ending values and changes that occurred during the period, it orders the periods by alternating the instants and durations, in increasing date order.

The start (and end) date-time of a duration-type fact should appear as the date-time of at least one instant-type fact shown in the same movement analysis presentation group.

The date-time of an instant-type fact shown with a period start (or end) label should appear as the start (or end) date-time of at least one duration-type fact shown in the same movement analysis presentation group.

6-00

6.26.3

A statement of changes in equity should contain at least one duration-type fact with starting and ending date-times matching instant facts at those date times.

Presentation base sets may be recognized as representing statements of changes and laid out with sets of rows having alternating instant and duration-type elements (6.24.10). The special layout is not needed unless there is at least one duration-type fact that represents the change in value from one instant to another, even if it is a nil-valued fact used as a placeholder.

6-00

6.26.3

Facts of type "text block" having text content containing an embedding command must have valid embedding command syntax.

A text block fact may contain an Embedding Command as detailed in Section 6.25. The following text is an example of an embedding command:

~ http://xbrl.sec.gov/rr/role/ShareholderFeesData
column period compact *
row dei_LegalEntityAxis compact eg_AaaMember eg_BbbMember
row rr_ProspectusShareClassAxis compact *
~

The beginning and ending "~" (tilde, ASCII hex 7E) indicate that the content of the enclosing element is an embedding command. Any text appearing before the first or after the second tilde is ignored.

An embedding command consists of one role URI followed by zero or more iterators. Each iterator consists of case-sensitive tokens separated by whitespace.

The role URI must be the role URI of presentation relationships used to display the facts or contain the substring "BarChart".

Any token with "_" (underscore, ASCII hex 5F) must denote an element. The text before the first underscore is the element preferred namespace prefix as defined in paragraph 6.7.7. The string after the first underscore must be nonempty and must be the element local name.

The first token of an iterator must be "row" or "column".

The second token of an iterator may be "period", "unit", "primary", or a token with an underscore that denotes an Axis as defined in 6.7.23.

The third token is the word "compact" or "nodisplay".

The fourth and subsequent token(s) is either "*" meaning "all", or tokens with underscores that each denote a Domain Member as defined in 6.7.27.

6-00

6.26.5

An embedding command must have at least one row iterator and one column iterator, either explicit or defaulted.

The default columns are period and unit, and the rows are all other axes (prior to transposition, which reverses rows and columns).

6-00

6.26.6

An embedding command and its presentation relationships should together provide an ordering of row axes and column axes for all facts it displays.

The order of axes displayed on rows and the axes displayed on columns takes into account the order of iterators in the embedding command. For axes not named in the embedding command but used in the contexts of facts to be displayed, axis ordering is determined by the presentation group whose role URI is that of the embedding command.

6-00

6.26.7

A Bar Chart should select at least one Annual Return fact.

When the role URI of an embedding command as detailed in section 6.24 contains the substring "BarChart" then its row and column iterators define a set of Annual Return facts, and the set should not be empty.

6-00

6.26.8

A Bar Chart must select no more than twenty Annual Return facts.

When the role URI of an embedding command as detailed in section 6.24 contains the substring "BarChart" then its row and column iterators define a set of Annual Return facts, and the set must not contain more than twenty facts that are not duplicates (as defined by 6.5.12).

6-00

6.26.9

An embedding command should not have both "{Elements}" in the definition text of its URI, and an iterator with direction token "column" and axis token "primary".

The text "{Elements}" forces the primary axis to be displayed as rows.

6-00