6.3.3

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

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

A submission must contain exactly one EX-101.INS or EX-99.K SDR.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.3.10

A submission must contain at least one company extension schema EX-101.SCH or EX-99.SDR K.SCH.

A company extension taxonomy might be as simple as single schema that defines the namespace to be used by the company, and contains xsd:import elements for the relevant base taxonomy schemas. In most cases, though, the company extension taxonomy will consist of a schema and several linkbases.

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

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

6.4.3

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

6.5.1

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

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

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

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

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

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 attributes effective values, respectively, unless their values are consistent, as described below, in which case the distinct facts are consolidated into a single fact for all other validations.

For numeric facts, all such values must be consistent with having been rounded from a single value. Where the decimals attribute of such of facts is the same, the values MUST be numerically equal. Where the decimals attribute is different, consistency is determined by considering a closed interval centered on each fact value, and of size 10^(- n ) where n is the value of the decimals attribute, and checking for overlap of all such intervals. For example, a value of 500 with a decimals attribute of -2 would result in an interval of 450 to 550, inclusive. A value of 550 with decimals attribute of -1 results in an interval of 545 to 555. These values are considered consistent as the intervals overlap; they are both consistent with having been rounded from a value in the range 545 to 550. The use of a closed interval means that intervals are inclusive of the end values.

Consistent numeric facts are consolidated into a single fact having the value of the fact with the maximum specified decimals value for purposes of validation and rendering.

For non-numeric facts, the values are consistent only if they are V-Equal.

The xml:lang attribute effective value is relevant only for types derived from normalizedStringItemType or stringItemType. 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, and specifies that non-numeric values are compared after whitespace normalization.

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

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

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:

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.

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.

^*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).

6.5.22

All other elements in the dei namespace are optional.

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

Form SDR may have multiple EX-99.L SDR Exhibits, each with a separate EX 99.L SDR.INS attachment. The set of EX 99.L SDR.INS attachments whose xbrli:identifier is not 0000000000 must have distinct values of xbrli:identifier, and the set of EX 99.L SDR.INS attachments whose xbrli:identifier is 0000000000 must have distinct values of dei:EntityRegistrantName in the Required Context.

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

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

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

6.5.29

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

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

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

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

6.5.38

Do not use the forever period in contexts.

6.5.39

The dimension of xbrli:typedMember must be defined in a standard taxonomy.

The value of the dimension attribute must resolve to an element whose namespace-uri denotes a standard taxonomy schema as defined in 6.3.9. In a standard taxonomy, the xbrldt:typedDomainRef attribute will only refer to an element having 'simple' content as defined in XML Schema.

6.5.40

Submission header elements and entity data values for reporting period, company type, company status, and other data should be consistent with a fact of a corresponding standard element in the required context and in the absence of a submission header element, there should be no such matching fact.

As described in the EDGARLink Online Technical Guide, many submission types require certain XML tags and values to appear in the submission header while disallowing others. For example, submission type 10 Q requires element emergingGrowthCompany, but not acceleratedFilerStatus. Note that older versions of the dei namespace do not have all the relevant elements, while 6.5.20 and 6.5.21 in some cases require a fact in the required context that will not appear in the submission header, so the conditions for each such element may differ slightly. The following cases apply:

1. If an instance has dei:CurrentFiscalYearEndDate in the required context, then its month and day should match the fiscal year end month and day, if known, for the filer with CIK matching the required context xbrli:identifier.
2. If a submission header has a periodOfReport element then its date should agree with the value of dei:DocumentPeriodEndDate in the required context. This does not apply when 6.5.20 requires dei:DocumentPeriodEndDate for a submission type that does not have periodOfReport in the header.
3. If a submission has a voluntaryFilerFlag element then its value should agree with the value of dei:EntityVoluntaryFiler in the required context. This does not apply where 6.5.21 requires dei:EntityVoluntaryFiler for a submission type that does not have voluntaryFilerFlag in the header.
4. If a submission has a wellKnownSeasonedIssuerFlag then its value should agree with the value of dei:EntityWellKnownSeasonedIssuer in the required context. This does not apply where 6.5.20 requires dei:EntityWellKnownSeasonedIssuer for a submission type that does not have wellKnownSeasonedIssuer in the header.
5. If a submission has a shellCompanyFlag and there is a EntityShellCompany element in the dei namespace in the DTS of the instance, then the required context should have a dei:EntityShellCompany fact with a value that agrees. If the header does not have a shellCompanyFlag then the required context should not contain such a fact.
6. If a submission has a emergingGrowthCompanyFlag then the required context should not contain such a fact.
7. If a submission has a exTransitionPeriodFlag and there is an EntityExTransitionPeriodFlag element in the dei namespace in the DTS of the instance, then the required context should have a dei:EntityTransitionPeriodFlag fact with a value that agrees. If the header does not have adei:EntityTransitionPeriodFlag then the required context should not contain such a fact.
8. If the submission type is 485BPOS or 497, it has an invCompanyType element in its header. If there is an EntityInvCompanyType element in the dei namespace of the DTS of the instance, then the required context should have a dei:EntityInvCompanyType fact with a value that agrees.
9. If the submission has a smallBusinessFlag and the dei namespace in the DTS of the instance has element EntitySmallBusiness, then the required context should have a dei:AcceleratedFilerStatus fact value not containing the words "Smaller Reporting Company" and a dei:EntitySmallBusiness fact with a value that agrees. If the dei namespace in the DTS of the instance does not have element EntitySmallBusiness then the required context should have an dei:AcceleratedFilerStatus fact value containing the words "Smaller Reporting Company".
10. If the submission has an acceleratedFilerStatus element with value "Large Accelerated Filer" then the required context should have a dei:FilerCategory fact value starting with "Large Accelerated Filer".
11. If the submission has an acceleratedFilerStatus element with value "Accelerated Filer" then the required context should have a dei:FilerCategory fact value starting with "Accelerated Filer".
12. If the submission has an acceleratedFilerStatus element with value other than "Large Accelerated Filer" or "Accelerated Filer" then the required context should have a dei:FilerCategory fact value not starting with "Large Accelerated Filer" or "Accelerated Filer".
13. If the submission has no acceleratedFilerStatus element and dei:FilerCategory is not required by 6.5.20 then dei:FilerCategory should not appear in the required context.

6.5.41

For submission types 485BPOS and 497, each series identifier in the scope of the submission should appear as a member of dei:LegalEntityAxis in at least one context.

The series identifiers in the scope of a submission can be determined in one of two ways. If the submission header element rptIncludeAllSeriesFlag is true, then the scope is all active series IDs for all CIKs in the header. Otherwise, the scope contains the set of all values of the seriesId element children of rptSeriesClassInfo. Each series ID in scope should appear as a member of the dei:LegalEntityAxis with element name matching the series ID followed by the word "Member". For example, if the submission header contains:

  <seriesClasses xmlns="http://www.sec.gov/edgar/coregsc">
    <reportSeriesClass>
      <rptSeriesClassInfo xmlns="http://www.sec.gov/edgar/sccommon">
        <seriesId>S000123456</seriesId>
        <includeAllClassesFlag>true</includeAllClassesFlag>
      </rptSeriesClassInfo>
    </reportSeriesClass>
  </seriesClasses>
  

Then there should be at least one context with an explicit member of the dei:LegalEntityAxis whose local name is S000123456Member.

6.5.41

For submission types 485BPOS and 497, each series identifier in the scope of the submission should appear as a member of dei:LegalEntityAxis in at least one context.

The series identifiers in the scope of a submission can be determined in one of two ways. If the submission header element rptIncludeAllSeriesFlag is true, then the scope is all active series IDs for all CIKs in the header. Otherwise, the scope contains the set of all values of the seriesId element children of rptSeriesClassInfo. Each series ID in scope should appear as a member of the dei:LegalEntityAxis with element name matching the series ID followed by the word "Member". For example, if the submission header contains:

  <seriesClasses xmlns="http://www.sec.gov/edgar/coregsc">
    <reportSeriesClass>
      <rptSeriesClassInfo xmlns="http://www.sec.gov/edgar/sccommon">
        <seriesId>S000123456</seriesId>
        <includeAllClassesFlag>true</includeAllClassesFlag>
      </rptSeriesClassInfo>
    </reportSeriesClass>
  </seriesClasses>
  

Then there should be at least one context with an explicit member of the dei:LegalEntityAxis whose local name is S000123456Member.

6.5.42

Facts, Axes, or Members should not use an element name that has been declared "deprecated" in any version of its standard namespace.

Each time the edgartaxonomies.xml file is updated with allowed versions of standard namespaces (see 6.22) newer namespaces are normally accompanied with a list of elements from earlier versions that have been deprecated. Subsequent submissions should no longer use the deprecated elements.

For example, suppose element Xyz exists in us-gaap 2018 and is used in a submission that is accepted in February 2019. The new us-gaap 2019 taxonomy then deprecates element Xyz. Subsequently, on March 1st, 2019, us gaap 2019 is added to the standard taxonomies. Subsequently, the submission previously using Xyz will still be accepted but with an XBRL warning.

6.5.43

Facts having an element name in a standard namespace that is declared "not negative" and not having a contextRef attribute to a context with a consolidation or adjustment axis and an elimination or adjustment member should not have negative values.

Sections 6.6.8, 6.6.10, 6.6.11, and 6.6.30 discuss appropriate tagging of numeric values and the distinction between a fact value and its presentation with or without brackets. Standard elements such as OtherExpenses appearing on a consolidated income statement should never be negative; a negative value suggests that element OtherIncome is likely to have been more appropriate. In a consolidating income statement, however, a negative value of OtherExpenses is appropriate when it is an intercompany elimination.

The declaration of numeric elements, combinations of axis and member that should not appear with negative (or positive) values are published at https://www.sec.gov/info/edgar/signwarnings.json and updated at the same time that edgartaxonomies.xml is updated (see 6.22).

6.5.44

Custom axis elements that duplicate the purpose of standard namespace axis elements should not be used.

The table below shows a few widely used standard namespace axis elements, each playing an important disaggregating or other role in financial reporting. Instances should use these axes instead of custom axes whose names are minor variations. For example, instead of a custom element such as Product "Line", Product "Category" or Product "Type" axis, filers should use the "ProductsOrServices" axis instead.

Each time the edgartaxonomies.xml file is updated with allowed versions of standard namespaces (see 6.22) the file https://www.sec.gov/info/edgar/preferredaxes.json may be updated with patterns of custom axis names that will result in XBRL warnings.

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

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

6.7.8

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

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

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

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.

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 (level i) should appear after base sets containing the contents of Statements (level i).
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) should appear after all base sets tagged at level (i).
8. A base set with presentation relationships for a Footnote tagged at level (iii) should appear after all base sets tagged at level (ii).
9. A base set with presentation relationships for a Footnote tagged at level (iv) should appear after all base sets tagged at level (iii).
10. Base sets with {Type} 'Document' should appear before all other base sets as Cover" pages with level "0".

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.

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

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

6.7.14

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

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

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

6.7.19

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

6.7.20

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

6.7.21

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

6.7.23

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

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

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

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

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

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

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

6.12.1

The link:presentationArc element requires an order attribute.

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

Each effective presentation relationship 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. The root element is normally abstract, but need not be (6.13.3).

6.12.7

An effective 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.12.8

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

As described in section 6.24, an axis element (defined at 6.8.20) appearing in an effective presentation relationship base set without any child elements will filter out all facts and prevent the entire base set from being used for presentation.

6.12.9

A base set having one effective presentation relationship whose target has the same local name as the unitRef attribute value of a fact of a source or target element in the same base set should provide an ordering for all such unitRef attribute values.

As described in 6.24, the renderer displays sets of facts having multiple units of measure that cannot be merged into columns (or rows) in one of two ways. Either the units are ordered by the order they are declared in the instance, or by using the built-in unit axis ordered by relationships in a presentation base set. The presentation base set should either order all the units used, or none of them, so that the ordering is not mixed.

6.14.1

Element link:calculationArc requires an order attribute.

6.14.2

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

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

Element link:definitionArc requires an order attribute.

This ensures an intentional displayed order of definition relationships.

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

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

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

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

Presentation Groups

A "presentation group" is an effective presentation relationship base set. Section 6.13.3 described the content of presentation groups.

The relationships in a presentation group form a directed graph with one root element (see 6.12.7) having child elements in a fixed order, child elements of those elements each in a fixed order, and so on. Each presentation group has a single role URI and definition text as described in sections 6.7.9 through 6.7.12.

The overall order of presentation groups in the set of reports for a single instance is determined by the "SortCode" token described in 6.7.12.

The simplest report layout is one in which the presentation group contains no Axis or Domain Member elements. All of the facts in the instance whose elements appear as sources or targets of relationships in the presentation group in contexts having no xbrli:segment elements are displayed in the R-file. The facts are arranged into columns, one for each context. The presentation group, when traversed top down and in order, determines the order that the elements appear in the rows.

6.24.2

Context Selection

Contexts are selected for display by a presentation group by comparing the axis and their descendant members appearing in the group to the axes and members appearing in the context xbrli:segment. All contexts are selected in every presentation group except:

1. If a context segment has an axis with a member for which the axis does not have that member as a descendant in the presentation group does not appear in the base set, then the context will not be selected (it will be filtered out).
2. If the presentation contains an axis that does not have its default member as a descendant, and the context segment has no member for that axis, then the context will not be selected.

A warning is issued if the presentation group has axes but lacks descendants that would allow any context to be selected (6.26.1).

Contexts cannot be filtered based on anything other than the contents of xbrli:segment.

The set of periods in a set of contexts are on its Built-in Period Axis, or simply "period axis"

6.24.3

Unit Selection

Units are always selected for display in a presentation group. The set of units is on the Built-in Unit Axis, or simply "unit axis".

6.24.4

The Primary Axis

Elements in a presentation group that are not axis elements, not member elements, and do not have same local-name as a unitRef attribute value, are collectively called members on the Built-in Primary Axis, or simply "primary axis".

6.24.5

Fact Selection

Non-numeric facts are selected for display when their context is selected and their element is on the primary axis.

Numeric facts are selected for display when their context is selected and their element is on the primary axis.

The values of @xml:lang, @xsi:nil and @decimals have no effect on selection whether present or not.

When there are duplicate facts as defined by 6.5.12, only one fact is selected.

6.24.6

Layout as Columns and Rows

A set of facts to be displayed has, at a minimum, a primary axis and a period axis. If there are numeric facts, it also has a unit axis. If the contexts have xbrli:segment elements then it has a set of additional axes. To lay out a report, every axis with more than one member must be assigned a layout direction (column or row) and if there is more than one axis per direction, they must be nested.

In the default layout, the period axis is on the columns and the primary axis is on the rows. For example:

If there is a Unit axis, the units are on the Columns. If there are any other axes, they are on the rows. The nesting of the columns in the default layout is:

• The period axis is outermost;
• The unit axis is innermost.

For example:

The nesting of rows in the default layout is:

• The primary axis is innermost;
• Other axes are nested from outermost in, according to the order in which their axis element appears in the presentation base set.

For example, if the presentation base set had ordered the "Entity" Axis before the primary axis with a default member and one member "ABS Subsidiary", then the nesting would appear as follows:

A warning is issued when the nesting of axes cannot be determined (see 6.26.6).

6.24.7

Member Ordering

Each axis has a characteristic ordering of its members either implicitly for all built-in axes (primary, period and unit) or explicitly by the order of axis member elements in each specific presentation group.

When the period axis is on the columns, the periods are ordered first by durations before instants, then by increasing duration, and then by descending end date. For example:

The order of elements along the primary axis is determined by traversing the presentation relationships top-down, with parents before their immediate children, and the immediate children ordered by the value of the order attribute ascending.

If there is no Unit Axis in the presentation base set, units are ordered by their order of appearance in the instance (6.12.9). The example above using USD and CNY would appear if the USD unit appeared in the instance before the CNY unit.

If there is more than one value of attribute xml:lang appearing on facts in the instance, then there is an implicit Language Axis in which facts with language "en-US" appear before all others, and the other language codes appear in case-insensitive lexical order.

The order of members along any other axis is determined in the same way as for the primary axis, by traversing the presentation base relationships. Conventionally, the default member of the axis appears first without any label, as illustrated in the "ABC Subsidiary" example above.

6.24.7

Member Ordering

6.24.8

Merged Columns

If every column in the default layout represented a different combination of period and unit, then the display would often have empty space. In the examples below, the Revenue element is a duration-type element and the Assets element is an instant-type element, so that the figures could only appear this way:

Columns representing an instant period are instead shown merged with the columns representing durations that end on that date:

A set of facts with different units all on distinct elements may be merged into a single column as well. In particular, when facts whose unit is a currency, facts with units "shares", and facts whose unit is that same currency "per share" have compatible periods, they are merged into the same columns.

6.24.9

Period Start labels

An instant-type element of the primary axis that has a period start preferred label (see 6.12.7) results in a special kind of layout and column merge called a movement analysis. In a movement analysis, duration-type facts are matched to instant-type facts whose date-times are the same as its start and end dates. The same fact may thus appear as the ending value of one column, and the starting value of another. In the example below, the fact shown as YYY,YYY at Dec 31, 2012 is at the end of one period and the start of the next:

In general, the starting and ending balance facts should be matched with at least one fact representing the duration between them, otherwise a warning may be issued (6.26.2).

Note that the order of elements along the primary axis is preserved and does not affect whether the layout is considered a movement analysis; the following example is equally valid, resembling a statement of cash flows:

6.24.10

Column Headings and Promotion

If all column headings share the same units or period, then those axes are "promoted" into the upper left corner of the layout to avoid redundancy.

6.24.11

Row Headings and Promotion

The text shown in each row heading on the primary axis is the text of preferred label on that element position on the primary axis (see 6.11.4).

The text shown for non-primary axis members is a concatenation of the outermost member name label, followed by a vertical bar "|", followed by the next outermost member name label, and so on.

If the default member of an axis is the first number shown in order on that axis, its label is considered blank.

Any member that is not the only member shown for a given axis in that report is promoted into the upper left corner of the layout.

6.24.12

Footnotes and Merging

Footnotes of a report are displayed at the bottom of a report, sequentially numbered, and the footnote marks are numbers that appear as a superscript to the right of each fact to which they refer.

Every report's footnote numbering is local to that report, so that if a fact with a footnote is displayed in two different reports, it will be displayed with the same footnote text at the bottom of the report, but a different superscript number.

If all of the facts on a row have the same footnote mark, then that footnote mark is removed from the facts and "merged" to a position just to the right of the row labels and removed from the cells.

If all of the facts on a column have the same footnote mark, then that footnote mark is "merged" into the heading of the column and removed from the cells.

6.24.13

Flow Through Suppression on Statements

"Flow through" occurs when a fact is selected for display in more than one presentation group. One of the most common examples is that "Net Income" appears on both an income statement and a statement of cash flows.

Only presentation groups for which the "Type" token as described in 6.7.12 has the value "Statement" are subject to "flow through" suppression.

When a statement contains a column of facts that are all rendered in a column of some other presentation group, the column that is a subset of the other is removed (suppressed).

If columns in two statements have identical facts, then the column in the statement that appears first according to "SortCode" (6.7.12) is retained.

6.24.14

Cash Flow Statements

Presentation base sets for which the "Type" token as described in 6.7.12 has the value "Statement" and the "Title" text contains the word "cash" followed by "flow", then the only columns shown are those with the longest duration and those which have at least one-fourth the number of rows containing values as the columns with longest duration.

This is a special case of flow through suppression; without it, a typical cash flow statement for a 3rd quarter financial statement might display unwanted columns.

6.24.15

Statements of Changes in Shareholder Equity

Presentation base sets for which the "Type" token has the value "Statement", that present facts with period start and period end labels, and the "Title" text does not contain "parenthetical" but does contain the case insensitive pattern:

1. "stockholder", "shareholder", or "changes" in addition to either "equity" or "deficit", or
2. "partners" or "accounts" in addition to "capital", or
3. "statement" and "equity"

1. Period
2. Scenario
3. Primary
4. Creation Date
5. New Accounting Pronouncements
6. Adjustments for Change in Accounting Principle
7. Error corrections and Prior Period Adjustment

1. Legal Entity
2. Equity Components
3. Partner Capital Components
4. Class of Stock
5. (All other axes present)
6. Unit

1. Previously Reported
2. Restatement Adjustment
3. Change In Accounting Principle
4. Unspecified (the default)

If the set of facts presented does not contain instant-type facts and duration-type facts in the expected alternating arrangement, a warning may be issued (see 6.26.3).

6.24.15

Statements of Changes in Shareholder Equity

Presentation base sets for which the "Type" token has the value "Statement", that present facts with period start and period end labels, and the "Title" text does not contain "parenthetical" but does contain the case insensitive pattern:

1. "stockholder", "shareholder", or "changes" in addition to either "equity" or "deficit", or
2. "partners" or "accounts" in addition to "capital", or
3. "statement" and "equity"

1. Period
2. Scenario
3. Primary
4. Creation Date
5. New Accounting Pronouncements
6. Adjustments for Change in Accounting Principle
7. Error corrections and Prior Period Adjustment

1. Legal Entity
2. Equity Components
3. Partner Capital Components
4. Class of Stock
5. (All other axes present)
6. Unit

1. Previously Reported
2. Restatement Adjustment
3. Change In Accounting Principle
4. Unspecified (the default)

If the set of facts presented does not contain instant-type facts and duration-type facts in the expected alternating arrangement, a warning may be issued (see 6.26.3).

6.24.16

Layout Qualifiers

In addition to general layout and formatting rules there are additional ways of altering a layout by modifying the role definition text. When the tokens "Unlabeled", "Elements", or "Transposed" (case sensitive) appear in the definition text between curly braces "{...}", then one of three transformations apply:

1. When the definition text contains the token "{Unlabeled}", then the elements' labels do not appear in the leftmost column.
2. When the definition text contains the token "{Elements}", then the display has an additional column to the right of the labels, showing the element id. The {Elements} display can be useful for reviewing all the detailed content of an Interactive Data instance. {Elements} cannot be used with the period axis on the rows.
3. When the text contains the token "{Transposed}", then the entire display, after any other layout has been applied, is transposed (rows on the columns and vice versa).

If more than one layout qualifier is present in a definition text, all are ignored.

6.24.17

Uncategorized Facts

Facts (and their duplicates) that are not selected for display by at least one presentation base set are shown in an "Uncategorized Facts" report. The report number for the Uncategorized facts is 9999 and it is shown as if it had the "Elements" layout qualifier.

6.24.17

Uncategorized Facts

6.24.18

Numeric Formatting

Numeric facts are scaled for presentation to reduce the appearance of redundant sequences of "000" groups. Each set of distinct units of facts selected for a report is scaled independently to preserve their significant digits. Note that this is performed only with respect to the fact values; the value of the decimals attribute of a fact does not directly affect this determination. For example, if there are three facts with unit USD:

• Revenues 1,000,000 USD, decimals=-6,
• Assets 100,000 USD, decimals=-3,
• Income 1,000 USD, decimals=0,

Cells in the layout have unit symbols assigned as follows:

1. Each numeric cell has a unit (USD, GBP, Shares, etc.). A nonzero number will be displayed with a prefix consisting of the unit.
2. If all of the cells in a column have the same unit, then the symbol is copied to the column heading and removed from the cells.
3. For the non-zero cells in each column, remove a symbol from the cell if it has the same unit as the immediately prior nonzero cell, unless it is in the last row.
4. For the non-zero cells, in each row, remove a symbol from a cell if it has the same unit as the immediately prior nonzero cell, unless it is in the last column.
5. If there is a unique symbol for the unit ($, £, ¥, €, etc.) use that symbol as a prefix instead of the unit name as a suffix.

6.24.19

Non-numeric Formatting

Fact values may be non-numeric; the following rules apply when displaying non-numeric values of an element:

1. A date item type is displayed with format "mmm d, yyyy";
2. A time item type is displayed with format "hh:mm:ss";
3. A datetime item type where the time part is not 00:00:00 is displayed with format "mmm d, yyyy hh:mm:ss";
4. A duration item type (the value looks like "P..Y..M..D..H..M..S") is formatted as ".. years, .. months, .. days, .. hours, .. minutes and .. seconds", omitting any zero values.
5. A fact value that matches the regex for an XML QName "[_A Za z][A Za z]*:[_A Za z][A Za z0-9]*" is displayed as follows:
   1. If the QName is being displayed with preferred label p and it has preferred label p in this DTS, then display that label value;
   2. If the QName as a standard label in this DTS, then display that standard label value;
   3. Otherwise display the QName unchanged.
6. A string that matches the regex "?![~]*~\s+{URI}\s+?![~]*~.*" is interpreted as an embedding command;
7. A string that contains the "<" character followed by a QName and whitespace, "/>" or ">" is interpreted as escaped XHTML and is rendered as XHTML.
8. Otherwise the string is copied to the output unchanged.

6.24.20

The Filing Summary

In addition to individual R-files, the renderer produces a Filing Summary file that contains data about the input files, each R-file output, warnings and error messages logged during processing, and other information.

In particular, the Filing Summary contains for each report a computed "menu category" to assist in organizing a hierarchical menu for all reports. The renderer computes the menu category by analyzing the report's role definition text (6.7.12) as follows:

SortCode determines the order of appearance (6.24.1).

Type distinguishes between statements and non-statements.

Title is text to be displayed in the menu augmented with the following patterns: "(Policies", "(Tables", "(Details", layout qualifier tokens (6.24.16), and text that indicates cash flows (6.24.15) and statements of changes in equity (6.24.16).

The order of appearance and patterns in the Title for a single Interactive Data instance are processed as follows:

Note that the reports are categorized in order of appearance, and their category may depend on what report categories have already appeared.

An Uncategorized Facts report, if present, would always be in the last position by virtue of being report number 9999.

6.24.21

Multiple Instances

EDGAR submissions may have multiple Interactive Data instance document attachments. The renderer processes them all together in the same order that the instances appeared as EDGAR attachments. There is a single Filing Summary file output, and all the reports are numbered sequentially starting at 1. Each instance has a separate set of menu categories. When assigning a Menu Category as described in 6.24.19, any report whose SortCode is less than the SortCode of the previous report marks the beginning of a new set of menu categories.

If there are multiple instances each with uncategorized facts, they are numbered in descending order 9999, 9998, etc.

6.24.22

Workbook Output

The filing summary and reports are processed to produce a spreadsheet workbook. Each report is shown as a separate sheet, with a name derived from the first 32 characters of the presentation base set title. Each fact is presented in a spreadsheet cell. Formatting of individual numeric and non-numeric facts is simplified as compared to the report HTML format.

6.25.1

Embedding Commands

Conventional rendering of Interactive Data consists only of one report per presentation base set. These are called the "top level" reports. Embedding commands allow additional reports that are not at top level. A text block fact may contain an embedding command, which is a section of XHTML that looks like the following, anywhere in the text block:

~ http://xbrl.sec.gov/rr/role/ShareholderFeesData
column period compact *
row dei_LegalEntityAxis compact eg_S000005977Member
row dei_ProspectusShareClassAxis compact *
~ Comments can go here

The purpose of an embedding command is to identify a presentation base set, select a subset of the contexts to display, and display the resulting report in place of where the content of the text block would have been shown. An embedding command consists of:

• One Role URI, which identifies the presentation base set to use for the layout;
• A list of "iterators", each of which:
  • Places one of the axes (primary, period, unit, as described in 6.24.4 and 6.24.5) on either the rows or columns.
  • identify the style of that axis display (compact or nodisplay);
  • indicates which members of the axis may appear in the selected contexts (6.24.2).

A "compact" display means that each axis member is shown on a separate row (or column) with its label; a "nodisplay" means that the label is not shown.

Embedding layouts do not support the use of period start and period end preferred label roles.

Embedding command syntax, and the possible warning messages that may result from processing the command, are detailed in 6.26.4 through 6.24.6.

6.25.2

Bar Charts

When an embedded command has a role URI that contains the case sensitive text "barchart" and the primary elements are drawn from the set rr_AnnualReturn1990, rr_AnnualReturn1991, and so forth, then the renderer produces a graphic instead of a conventional table. Up to 20 facts may be shown. The bar chart has a fixed height and auto-scales vertically; it has fixed width horizontal bars. For example, three facts are displayed in the graphic shown below:

Although it is not necessary, the horizontal width of the graphic can be adjusted by adding 'nil' valued facts.

Footnotes on the fact values are ignored.

6.26.1

An effective presentation relationship base set that has an Axis element without its default member as a descendant in should display at least one fact having an non-defaulted member on that axis.

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

6.26.2

Facts presented in an effective presentation relationship base set using period start or period end preferred labels should contain alternating instant and duration facts.

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.

An effective presentation relationship base set 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 decreasing duration and increasing end date order.

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

An effective presentation relationship base set that is recognized as representing a statement of changes is a table 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.26.4

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:

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.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, the default rows are primary, and the the columns are all other axes (prior to transposition, which reverses rows and columns).

6.26.6

An embedding command and the effective presentation relationship base set designated by its role URI 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 first takes into account the order of iterators in the embedding command. Then, for axes not named in the embedding command but used in the contexts of facts to be displayed, axis ordering is determined by the effective presentation relationship base set whose role URI is that of the embedding command.

6.26.7

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

When the role URI of an embedding command as described 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.26.8

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

When the role URI of an embedding command as described 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.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 layout qualifier "{Elements}" forces the primary axis to be displayed as rows.