Rule | Text | Page
--- | --- | ---
## 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 (&quot; &amp; &apos; &lt; and &gt;). To include characters greater than 127, use XML numeric character references. For example, &#xAE; and &#174; are ASCII sequences producing the ® symbol. REMARK: This test suite does NOT test to see that only the subset of ASCII allowed by 5.2.1.1 are used. | 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. REMARK: the files e60305001ng-20081231.xml and e60305002ng-20081231_lab.xml are not even good XML, so don't try to process them as such. | 6-5
## 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 EDGARLink 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 1.0 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. REMARK: there are no 2009 taxonomy examples here because the focus is on href syntax. REMARK: xml:base is forbidden. REMARK:RFC 2396defines URI syntax | 6-5
## 6.3.8 | ## A submission must contain exactly one EX-100.INS or EX-101.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. | 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. REMARK: Only 2008 taxonomies are used in these tests, but that does not matter, it is a test of xml:base. | 6-6
## 6.4.3 | ## The XBRL instance documents in a submission must be XBRL 2.1 valid. Each instance document in the filing is tested separately for XBRL 2.1 validity. In order to increase the likelihood that XBRL documents within an EDGAR submission pass validation, filers are encouraged to validate their XBRL documents for compliance with the XBRL 2.1 Specification prior to submission. REMARK: This obviously does not test all XBRL 2.1, only those areas that have been known to cause problems. REMARK: At this time, only one instance is allowed per submission. REMARK: XBRL 1.0 Dimensional validity is required also. | 6-7
## 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. 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. For example, a public holding company with separately reporting subsidiaries may report the subsidiaries in several, separate instances in the same submission. 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. REMARK: Variations 001ng and 002ng may produce error 60523 depending on implementation. | 6-7
## 6.5.3 | ## All xbrli:identifier elements in an instance must have identical content. REMARK: this will inevitably generate two errors . | 6-7
## 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-7
## 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 original HTML/ASCII document represents a reporting period of one quarter or longer, then the same date must not appear as the content of both an xbrli:startDate and an xbrli:endDate in an instance. This rule applies if the document type is one of 20-F, 40-F, 10-Q, 10-K, 10, N-CSR, N-Q, or N-CSRS. Note that XBRL 2.1 interprets a date used as a context start date as "midnight at the beginning of" that day. A date used as an instant or endDate in a context means "midnight at the end 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 will not have any contexts with start date time of midnight at the beginning of 2008-05-31, and no contexts with end date-time of midnight at the end of 2008-06-01. REMARK: 6.5.9 applies to all context start dates compared against all context end dates, irrespective of segments. | 6-8
## 6.5.10 | ## If the original HTML/ASCII document represents a reporting period of one quarter or longer, then the same date must not appear in the content of an xbrli:startDate and an xbrli:instant in the same instance. This rule applies if the document type matches any of 20-F, 40-F, 10-Q, 10-K, 10, N-CSR, N-Q, or N-CSRS. For example, a company with 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). But it must not have any instant contexts with the date-time of midnight at the end of 2008-06-01. REMARK: this applies to all pairs of duration and instant contexts. It is not necessary to test a context's start and end dates against itself because XBR2.1 section 4.7.2 requires that startDate is strictly less than end date. REMARK: It is possible in principle that the measurement date for a public float or common shares outstanding might coincide with the start date of a period. Although that situation has not yet been observed in practice, an appropriate way to carve out an exception may appear in a future edition of the Manual. | 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. REMARK: Abbreviations are fromBase Units | 6-10
## 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. 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, respectively. A fact is an occurrence in an instance of an element with a contextRef attribute. The values of the id attribute and the text content of the element 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 as defined in the XBRL 2.1 specification. The V-Equal test is sensitive to the underlying data type, so the decimals attribute of "-6" is V-Equal to decimals "-06.0". In unusual cases the same fact may be presented with different levels of detail, such as "123456 Shares with decimals equal to 'INF'", and "120000 Shares with decimals equal to '-3'". Instead of including both facts in the instance, the instance should contain only the more precise one. Duplicate facts have no benefit to users and are easily consolidated by the filer before submission. | 6-10
## 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. REMARK: This rule establishes what the default value of xml:lang is and therefore can only be indirectly violated by the violation of some other rule. Therefore the only error code that appears here is du-60512-Duplicate-Facts which normally would appear in 6.5.12. | 6-10
## 6.5.14 | ## An instance having a fact with non-nil content and the xml:lang attribute not starting with "en" must also contain a fact using the same element and all other attributes with an xml:lang attribute that begins with "en". The valid values of an xml:lang attribute that begin with "en" denote variants of English, such as "en", "en-US", and "en-UK" and match the pattern en|en-[A-Z][A-Z]. Non-English content may appear but it must be translated into English. For example, the English fact below can appear in an instance without the French fact, but the French fact cannot appear without the 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 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. If the ampersand character must appear in the well-formed XML, it must be doubly quoted as shown in the example above. | 6-11
## 6.5.16 | ## Facts of type "text block" 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. REMARK: Restrictions on the content of href are documented in EFM 5.2.2.1. There is aDTDused for validation of unescaped content, but a change to Schema (and therefore disallowing named entities) may occur at some time in the future. REMARK: For reference only, here are tags forbidden, keeping in mind that all permitted tags are lower case: <acronym/> <applet/> <area/> <base/> <basefont/> <bdo/> <button/> <col/> <colgroup/> <del/> <fieldset/> <font/> <form/> <frame/> <frameset/> <iframe/> <input/> <ins/> <label/> <legend/> <map/> <meta http-equiv='name' content='content'/> <noframes/> <noscript/> <object/> <option/> <param/> <q/> <s/> <S/> <script/> <select/> <span/> <style/> <tbody/> <textarea/> <tfoot/> <thead/> | 6-12
## 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-12
## 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 a filing such as a Form 10-Q for the last calendar quarter of 2009, with xbrli:startDate equal to '2009-10-01' and xbrli:endDate equal to '2009-12-31'. Many submissions require a second Required Context, see 6.5.21 below. Required contexts are distinguished by having no xbrli:segment elements. REMARK: At this point there is only one distinction, between 485BPOS and 497 which require a one day duration, and all other filings having any duration. At some point in the future the ERXL table will be extended to include columns that indicate the allowable range of durations, for example:
Forms | Shortest | Longest
--- | --- | ---
485BPOS, 497 | P1D | P1D
10-K, 10-K/A, N-CSR, N-CSR/A | P1D | P1Y
10-Q, 10-Q/A, N-Q | P1D | P9M
N-CSRS, N-CSRS/A | P1D | P6M
| 6-12
## 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, 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 EDGAR Form Types (Investment Management): 485BPOS, 497 , N-CSR, N-CSRS, N-Q, N-CSR-CSRS/A, N-Q | 10-Q/A1 8-K
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. REMARK There is a mapping from submission types recognised by EDGAR, to the valid values of the dei:DocumentType element. The mapping (submissionType,documentType) is:
EDGAR Form Type: | dei:DocumentType Value:
--- | ---
10 | 10
10/A | 10
10-K | 10-K
10-K/A | 10-K
10-Q | 10-Q
10-Q/A | 10-Q
20-F | 20-F
20-F/A | 20-F
40-F | 40-F
40-F/A | 40-F
485BPOS | 485BPOS
6-K | 6-K
6-K/A | 6-K
8-K | 8-K
F-1 | F-1
F-1/A | F-1
F-10 | F-10
F-10/A | F-10
F-3 | F-3
F-3/A | F-3
F-4 | F-4
F-4/A | F-4
F-9 | F-9
F-9/A | F-9
N-1A | N-1A
NCSR | NCSR
NCSR/A | NCSR
NCSRS | NCSR
NCSRS/A | NCSR
N-Q | N-Q
N-Q/A | N-Q
S-1 | S-1
S-1/A | S-1
S-11 | S-11
S-11/A | S-11
S-3 | S-3
S-3/A | S-3
S-4 | S-4
S-4/A | S-4
N-CSR | NCSR
N-CSR/A | NCSR
N-CSRS | NCSR
NCSRS/A | NCSR
497 | Other
| 6-12
## 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 with other languages starting with "en", which in turn 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 outstanding), otherwise identical to the Required Context. Additional facts using the Required Entity Information elements are allowed in other contexts.
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. 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-Q | 20-F | 40-F | 6-K, N-CSR, N-Q, NCSRS | 10, S-1, S-3, S-4, S-11 | 8-K, F-1, F-3, F-10, 497, 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 |  |  |
DocumentFiscalPeriodFocus | X | X | X | X |  |  |
REMARK: This set of test cases reflects the variations for the forms 20-F, 40-F, 6-K, 8-K, 10-Q, 10-K, 10, S-1, S-3, S-4, S-11, F-1, F-3, F-10, 485BPOS, N-CSR, N-Q, NCSRS as well as, implicitly 20-F/A, 40-F/A, 10-K/A, S-1/A, S-3/A, S-4/A, S-11/A, F-1/A, F-3/A, F-10/A, N-CSR/A, N-Q/A, NCSRS/A, 485BPOS and 497. Here is what form requires what element: 10-K: EntityRegistrantName, EntityCentralIndexKey, CurrentFiscalYearEndDate, EntityWellKnownSeasonedIssuer, EntityVoluntaryFilers, EntityCurrentReportingStatus, EntityFilerCategory, EntityPublicFloat, DocumentFiscalYearFocus, DocumentFiscalPeriodFocus; 10-Q: EntityRegistrantName, EntityCentralIndexKey, CurrentFiscalYearEndDate, EntityFilerCategory, DocumentFiscalYearFocus, DocumentFiscalPeriodFocus; 20-F: EntityRegistrantName, EntityCentralIndexKey, CurrentFiscalYearEndDate, EntityWellKnownSeasonedIssuer, EntityCurrentReportingStatus, EntityFilerCategory, DocumentFiscalYearFocus, DocumentFiscalPeriodFocus; 40-F: EntityRegistrantName, EntityCentralIndexKey, CurrentFiscalYearEndDate, EntityCurrentReportingStatus, DocumentFiscalYearFocus, DocumentFiscalPeriodFocus; 6-K, N-CSR, N-Q, NCSRS: EntityRegistrantName, EntityCentralIndexKey, CurrentFiscalYearEndDate, DocumentFiscalYearFocus, DocumentFiscalPeriodFocus; 10, S-1, S-3, S-4, S-11: EntityRegistrantName, EntityCentralIndexKey, EntityFilerCategory; 8-K, F-1, F-3, F-10, 497, 485BPOS: EntityRegistrantName, EntityCentralIndexKey; | 6-14
## 6.5.22 | ## All other elements in the dei namespace are optional. REMARK: The second variation is logically part of 6.5.20, but it generates no errors so that shouldn't matter. | 6-15
## 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-15
## 6.5.24 | ## he 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. 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-15
## 6.5.25 | ## Elements with a type attribute equal to or a restriction of 'us-types:domainItemType' must not appear as facts in an instance. Elements of this type are for use only in the xbrldi:explicitMember element. | 6-15
## 6.5.26 | ## An instance with dei:DocumentType of 10-K, 10-Q, 20-F, or 40-F 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] | [Result]
--- | --- | --- | --- | --- | ---
000 | 10-K | 0 | 0 | 0 | ng
001 | 10-K | 0 | 0 | 1 | ng
002 | 10-K | 0 | 1 | 0 | ng
003 | 10-K | 0 | 1 | 1 | ng
004 | 10-K | 0 | 2 | 0 | gd
005 | 10-K | 0 | 2 | 1 | gd
006 | 10-K | 1 | 0 | 0 | gd
007 | 10-K | 1 | 0 | 1 | gd
008 | 10-K | 1 | 1 | 0 | ng
009 | 10-K | 1 | 1 | 1 | ng
010 | 10-K | 1 | 2 | 0 | ng
011 | 10-K | 1 | 2 | 1 | ng
012 | 10-Q | 0 | 0 | 0 | ng
013 | 20-F | 0 | 0 | 0 | ng
014 | 40-F | 0 | 0 | 0 | ng
015 | N-Q | 0 | 0 | 0 | gd
016 | 8-K | 0 | 0 | 0 | gd
017 | 6-K | 0 | 0 | 0 | gd
018 | NCSR | 0 | 0 | 0 | gd
019 | 485BPOS | 0 | 0 | 0 | gd
020 | Other | 0 | 0 | 0 | gd
| 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. REMARK Although these variations each show only one error code, depending on a vendors' implementation, validation errors may occur prior to the error listed, or other errors may cascade after Footnote-Substitution-Group. As long as all variations marked NOGOOD are rejected because of the disallowed substitutionGroup, a validator may be considered as legitimately passing this testcase. | 6-16
## 6.5.28 | ## The xlink:role attribute of a link:footnote element must be defined in the XBRL Specification 2.1. REMARK The content of the link:definition element is irrelevant because the entire declaration is forbidden. | 6-16
## 6.5.29 | ## The xlink:role attribute of a link:loc element must be empty, or defined in the XBRL Specification 2.1. | 6-16
## 6.5.30 | ## The xlink:arcrole attribute of a link:footnoteArc element must be defined in the XBRL Specification 2.1. REMARK the arc role link:definition does not matter because the entire declaration is forbidden. | 6-16
## 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-16
## 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. REMARK: It would have been better instead of referring to "link:footnote element" to refer to "link:footnoteLink child element with @xlink:type of 'resource'". Likewise instead of "link:footnoteArc element" refer to "link:footnoteLink child element with @xlink:type of 'arc'". Then you will never get spurious errors if element substitutionGroups were to be allowed. | 6-16
## 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-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. REMARK: Because this applies only to company extensions, in principle there could be a test in which a standard taxonomy schema having an 'include' element would be 'GOOD', but there is no such standard taxonomy schema. | 6-28
## 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. REMARK:edgartaxonomies.xmlis the ONLY authoritative source of "standard taxonomies". | 6-28
## 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. REMARK: There is a mismatch between the date formats currently accepted by EDGAR, and the possible ISO8601 formats. | 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. REMARK: This only applies to a company extension schema. A standard taxonomy could in principle have an underscore in their namespace prefix, but there is no such standard taxonomy and therefore no such test variation. | 6-31
## 6.7.8 | ## Element xsd:schema must not contain any occurrences of "embedded" linkbases. REMARK: This applies only to company extension schemas. In principle a standard taxonomy is allowed to have an embedded linkbase. But there is no such standard taxonomy and therefore no such test variation. REMARK: there are no variations for linkbases other than link:labelLink, but the rule does apply to all of them. | 6-32
## 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> REMARK:http://www.ietf.org/rfc/rfc2396.txtnotes that the host component of a URL is case insensitive, a URI in Interactive Data documents has a case-sensitive host component. The same rfc allows characters in URIs that are not normally thought of as legal; variation 000gd exercises that in a minimal way without wading into the complex realm of XML character escaping versus URI character escaping. REMARK: This applies only to company extension schemas. In principle a standard taxonomy could have a different authority part in the targetNamespace and a role or arcrole declaration. There being no such standard taxonomies, there are no such 'gd' variations. | 6-33
## 6.7.10 | ## A DTS must not contain more than one link:roleType element with equal values of the roleURI attribute. REMARK: this applies to the entire DTS, not just the company schema which is what the similar XBRL 2.1 constraint applies to. | 6-33
## 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
REMARK: this applies only to company extension schemas, so that exceptions in the us-roles-YYYY-MM-DD.xsd schemas are not invalid. | 6-33
## 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} - {Title} 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: Each Statement must appear in at least one base set, in the order the statement appeared in the official HTML/ASCII document. 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. 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. All base sets containing the contents of Footnotes must appear after base sets containing the contents of Statements. A Text Block for each Footnote must appear in at least one presentation relationship in a base set. Each base set for a "Footnote as a Text Block" presentation link must contain one presentation relationship whose target is a Text Block. Base sets with presentation relationships for a Footnote tagged at level (ii) must appear after all base sets tagged at level (i). A base set with presentation relationships for a Footnote tagged at level (iii) must appear after all base sets tagged at level (ii). 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. REMARK: This applies only to company extension schemas, so that exceptions in the us-roles-YYYY-MM-DD.xsd schemas are not invalid. REMARK: This was never meant to apply to resource roles, and that will be corrected in a future release. REMARK: Because the (incorrectly percieved) importance of instance rendering has continued to increase beyond reason, the validator now enforces an even more stringent criterion than documented in manual version v13. The regex is "[0-9]+ \- {Statement|Disclosure|Schedule|Document} \-.*[^\s]"; this discrepancy between the text of the manual and the actual validation MUST be corrected in the manual ASAP. | 6-33
## 6.7.13 | ## The arcroleURI attribute of a link:arcroleType element must begin with the same {scheme} and {authority} parts as the targetNamespace attribute. REMARK: This applies only to company extension schemas. In principle a standard taxonomy schema could violate this, but there are no such taxonomy schemas and so no 'good' variation. REMARK: An arcrole definition should not have to match the same pattern as presentation definitions, but we do so in this testcase to avoid spurious errors. | 6-35
## 6.7.14 | ## A DTS must not contain more than one link:arcroleType element with equal values of the arcroleURI attribute. REMARK: this applies to the entire DTS not just company extension schemas. | 6-35
## 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. REMARK: The test for emptiness is done after trimming. REMARK: this applies only to company extension schemas, so if there were any exceptions standard schemas those would not be invalid. | 6-35
## 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. REMARK: onlyhttp://www.sec.gov/info/edgar/edgartaxonomies.xmldefines "standard taxonomy". | 6-36
## 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. REMARK: This only applies to the company extension schemas. If there were a standard taxonomy schema that violated this, it would nevertheless be good. There being no such standard taxonomy, there is no such test variation. | 6-36
## 6.7.18 | ## The nillable attribute value of an xsd:element must equal "true". REMARK: This only applies to the company extension schemas. If there were a standard taxonomy schema that violated this, it would nevertheless be good. There being no such standard taxonomy, there is no such test variation. REMARK: This was only meant to apply to element declarations in an xbrli substitution group. In the current EDGAR release, non-XBRL element declarations are effectively useless and if that were ever to change this rule should be changed and some new variations included. | 6-36
## 6.7.19 | ## The xsd:element substitutionGroup attribute must not be a member of a substitution group with head 'xbrli:tuple'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies other than the ICI 2006 taxonomy. Hence the inclusion of a 'good' case 003gd that imports the ICI 2006 taxonomy. It is 'GOOD' with respect to this rule, but has dozens of violations of other EFM rules. ICI 2006 can only be used with EX-100 attachments that are not subject to Chapter 6 validations. | 6-36
## 6.7.20 | ## An xsd:element must not have an xbrldt:typedDomainRef attribute. REMARK: This only applies to company extension schemas, although it also holds for all standard taxonomies. If there were a standard taxonomy that used xbrldt:typedDomainRef then there would be 'good' test variation covering it. | 6-36
## 6.7.21 | ## If the abstract attribute of xsd:element is 'true', then the xbrli:periodType attribute must be 'duration'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies other than the ICI 2006 taxonomy. The ICI 2006 taxonomy can only be used with EX-100 attachments, to which rules in Chapter 6 do not apply. | 6-36
## 6.7.22 | ## If the abstract attribute of xsd:element is 'true', then the type attribute must be 'xbrli:stringItemType'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies. If there were a standard taxonomy that violated this, it would appear in a 'good' test variation. REMARK: This is defined to require the type attribute to equal stringItemType. This means that domain items cannot be abstract. A future release might relax this rule so that elements of any type derived from 'string' could be abstract. | 6-36
## 6.7.23 | ## The xsd:element substitutionGroup attribute must equal 'xbrldt:dimensionItem' if and only if the name attribute ends with 'Axis'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies other than the ICI 2006 taxonomy. The ICI 2006 taxonomy can only be used with EX-100 attachments, to which rules in Chapter 6 do not apply. | 6-36
## 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'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies other than the ICI 2006 taxonomy. The ICI 2006 taxonomy can only be used with EX-100 attachments, to which rules in Chapter 6 do not apply. | 6-36
## 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'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies. If there were any such standard taxonomy it would be included in a 'good' test variation. REMARK: This does allow @substitutionGroup to be absent, so it would allow non-XBRL elements and that may have some use in some future EDGAR release. | 6-37
## 6.7.26 | ## If xsd:element name attribute ends with 'LineItems' then the abstract attribute must equal 'true'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies. If there were any such standard taxonomy it would be included in a 'good' test variation. | 6-37
## 6.7.27 | ## The xsd:element name attribute must end with 'Domain' or 'Member' if and only if the type attribute equals 'us-types:domainItemType'. An element is a "Domain" if and only if its name attribute ends with 'Domain'. An element is a "Member" if and only if its name attribute ends with 'Member'. REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies. REMARK: the wording really does require that specific type, not a type derived from it - not sure it is worth changing, but for consistency, variation 006gd ensures that derived types are ignored. | 6-37
## 6.7.28 | ## If xsd:element type attribute equals 'us-types:domainItemType' then the xbrli:periodType attribute must equal 'duration'. REMARK: this only applies to company extension schemas, although it holds for all standard taxonomies. If there were a standard taxonomy that violated the rule, it would appear in a 'good' test variation. | 6-37
## 6.9.1 | ## A link:linkbase must be XML Linking Language (XLink) 1.0 valid. Two syntax rules about elements with a type attribute equal to 'extended' ("extended-type links") require emphasis: The scope of the xlink:label attribute is only its enclosing extended-type link. The xlink:label attribute does not function like the XML id attribute, which must be unique in an entire document. Therefore, the same value of the xlink:label attribute may appear on any number of elements, so long as those elements appear in different extended-type links. Two elements with a type attribute equal to 'arc' ("arcs") in the same extended-type link must not have the same values for the xlink:from attribute and the xlink:to attribute, even if their xlink:arcrole attribute is different. However, this prohibition against duplicate arcs is unrelated to any XBRL or EDGAR level syntax rule that forbids equivalent arcs (XBRL 2.1 section 3.5.3.9.7.4). Reliance on these two rules of XLink syntax yields the meaning of the term 'base set' of arcs as defined in XBRL 2.1 and used elsewhere in this manual. REMARK: This applies to company extension linkbases, but no standard taxonomy linkbase violates it. | 6-45
## 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. | 6-46
## 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. REMARK: Note that type='extended' is handled by XBRL 2.1 so this really only applies to type='resource', and there are other rules for reference and footnote that would trigger errors if the xlink:role were missing. Therefore just one variation for the label resource, for now. REMARK: This only applies to a company extension linkbase, and RR 2008 is a standard taxonomy, hence case 000gd. | 6-46
## 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. REMARK: type='extended' is handled by XBRL 2.1 so this really only applies to type='resource', moreover, footnote and reference would be handled by other rules so this is only for labels. REMARK: This only applies to a company extension linkbase. There is no standard taxonomy linkbase that violates this rule, but if there were, it would be included in a 'good' test variation. REMARK: the roles declared in these tests have link:definition text that conforms to 6.7.12 even though 6.7.12 was only meant to apply to roles that are used on link:presentation. | 6-46
## 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. REMARK: This applies only to company extension taxonomies. The arc roles declared inhttp://www.xbrl.org/2005/xbrldt-2005.xsdare okay because that is a standard taxonomy location. The arc roles declared in US GAAP 2009 are not in a standard taxonomy location. | 6-46
## 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. REMARK: Although this error is caught at the EDGARLink submission (transport) level it is easy to verify before attempted submission. REMARK: This only applies to a company extension linkbase. There is no standard taxonomy linkbase that violates this rule, but if there were, it would be included in a 'good' test variation. | 6-46
## 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. REMARK: This only applies to a company extension linkbase. The RR 2010 standard taxonomy linkbase contains links with priority attributes of 10, and is therefore a 'good' test variation. | 6-47
## 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-47
## 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-47
## 6.10.3 | ## If an element used in an instance is assigned a label in the DTS whose xml:lang attribute does not start with 'en', then the DTS must also contain a link:label for the same element and all other attributes with an xml:lang attribute that starts with 'en'. Non-English labels may appear for elements in the schema, but they must be translated into English if they are used in an instance. | 6-47
## 6.10.4 | ## The DTS of an instance must have no distinct elements having the same English standard label. 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. REMARK: this restriction applies to all elements, not just those used in the instance. | 6-48
## 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. REMARK: This only applies to company extension linkbases. If edgartaxonomies.xml were to list a standard taxonomy linkbase containing 'documentation' label roles, then that standard taxonomy linkbase would be included in a 'good' testcase variation. | 6-48
## 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. REMARK: This only applies to company extension label linkbases. If a standard taxonomy label linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 6-48
## 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. REMARK: This only applies to company extension label linkbases. If a standard taxonomy label linkbase appearing in edgartaxonomies.xml were to violate this rule, then it would be included in a 'good' test variation. | 6-48
## 6.12.1 | ## The link:presentationArc element requires an order attribute. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 6-52
## 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. REMARK: this rule applies whether either of the elements in the presentation arcs used in an instance or not REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 6-52
## 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-52
## 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.14.1 | ## Element link:calculationArc requires an order attribute. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 6-54
## 6.14.2 | ## Element link:calculationArc requires a weight attribute value equal to 1 or -1. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 6-54
## 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. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. In fact, because there are no standard taxonomies that violate the rule, there is not even a variation that tests whether such a bad arc would be okay if prohibited. | 6-54
## 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. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. In particular, add this test: calculation arcs form a directed cycle, but one of the imported standard arcs is prohibited, GOOD. | 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. 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. REMARK: Should be "...single extended linkrole". | 6-54
## 6.16.1 | ## Element link:definitionArc requires an order attribute. This ensures an intentional displayed order of definition relationships. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 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. REMARK: Note that it is not necessary for the target element to be used in the instance, for this to be a violation. | 6-57
## 6.16.4 | ## The xlink:arcrole attribute 'http://xbrl.org/int/dim/arcrole/domain-member' 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 (or 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. REMARK: This rule does not define where DRS discovery should begin. The interpretation of the constraint that is least likely to cause filing rejectin, and therefore the one used here, is that DRS discovery begins at each separate dimension-domain relationship. This may become more restrictive in a future release, so implementors may wish to consider issuing a warning in cases such as the complex situation in variation _006gd. REMARK: The text "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" means that test case 007gd should have been 007ng. In the current EDGAR release, it is, and remains, 007gd. A future release will either strike this sentence from the rule OR change the testcase to 007ng. | 6-57
## 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. REMARK: This constraint does not take primary item inheritance into account, and therefore rules out the simplest uses of unions of 'all' hypercubes. A future release may take primary item inheritance into account and therefore implementors may wish to issue a warning in situations like that shown in variation 002gd. | 6-58
## 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. REMARK: This only applies to company extension linkbases. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation. | 6-58
## 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. REMARK: Ordinarily there would be a test here which would have a prohibited notAll arc somewhere; can't do that in this test because no standard taxonomy has a notAll, and the prohibition on ineffectual arcs prevents me from putting one in here. So those were variations 001 and 003 and they are not in here. REMARK: This rule is intended to ensure that the notAll arc does not forbid members of a dimension that is not even relevant to a hypercube. domain-member relationships between P1 and P2 are not relevant, since neither all nor notAll are ever consecutive from domain-member. Note that the rule assumes, but does not require, that the target roles on HcDim1 and HcDim2 are different, so that the members of Dim1 are different in HC1 and HC2. REMARK: The rule, as written, fails to make explicit that the condition can only be evaluated with respect to some primary item; without some primary item as a common ancestor, dimensions are irrelevant to each other. In variation 003ng, the element EntityTaxIdentificationNumber has a notAll, but no all (and neither does any ancestor in that role). | 6-58
## 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. REMARK: This rule complements 6.16.7 by ensuring that HC1 and HC2 are distinct. The combination of this constraint, 6.16.4, and XBRL Dimensions 1.0 constraint's prohibition of undirected cycles in HcDim relationships prevents using @targetRole to give the same HC element different members of the same axis. | 6-58
## 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. REMARK: Consecutive relationships are defined athttp://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm#_2.1.1and consist only of the following initial-following arc role pairs: all, hypercube-dimension; not-all, hypercube-dimension; hypercube-dimension, dimension-domain; dimension-domain, domain-member; domain-member, domain-member. Note that domain-member is never followed by all, not-all, or any arcrole other than domain-member. | 6-58
## 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. REMARK: A company extension also cannot remove or change references in standard taxonomies (this is a technical consequence of the rule prohibiting URI fragments other than shorthand xpointers). REMARK: This only applies to company extension linkbases. If there were a reference linkbase in edgartaxonomies.xml, then it would be included in a 'good' test variation. | 6-59
## 6.18.2 | ## A company extension reference linkbase must not add, remove or change references for any element declared in a standard taxonomy schema. REMARK: 6.19 reads "A company extension also cannot remove or change references in standard taxonomies (this is a technical consequence of the rule prohibiting URI fragments other than shorthand xpointers)." but this does not explicitly say the obvious point that you can't ADD authoritative references, either. | 6-59
## 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. REMARK: There is no such section 6.22.1, it is meant to refer to 'taxonomies that we allow'. Keep in mind thathttp://www.sec.gov/info/edgar/edgartaxonomies.xmlis the ONLY authoritative source of "standard taxonomies". In this test suite we test the allowed files in groups according to family and version (i.e., release). REMARK: This test leaves out USFRTF and ICI given that none of the other EDGAR validations apply to them. | 6-60
## 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. REMARK: There is no such section 6.22.2, it is meant to refer to 'files that are likely to be referenced but that actually we do not allow.'. Keep in mind thathttp://www.sec.gov/info/edgar/edgartaxonomies.xmlis the ONLY authoritative source of "standard taxonomies". In this test suite we test a subset of the disallowed files, one at a time. | 6-56
## 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. REMARK: There is no such section 6.22.3, these tests are just to verify that 2008 taxonomies work together but do not work with the 2009 or subsequent taxonomies because of the XBRL 2.1 level conflict between roleType declarations (when their allowed linkbases are included in the mix). Going forward, taxonomies of different vintages are expected to coexist in a DTS without XBRL-level errors and this testcase will not be necessary. | 6-56