Rule | Text | Page
--- | --- | ---
## 6.3.2 | ## XBRL instance, schema, and linkbase documents must be attached to an EDGAR submission using the EX-100.*, EX-101.*, EX-99.K SDR.*, or EX-99.L SDR.* document types. A single submission must not contain more than one of EX-100, EX-101, or EX-99.K SDR attachments. A submission may contain both EX-99.K SDR and EX-99.L SDR attachments. All XBRL document types are listed in the table below.
XBRL Document | XBRL Related Document Types | Interactive Data Document Types | Root Element | Required Element
--- | --- | --- | --- | ---
Instance | EX-100.INS | EX-101.INS, EX-99.K SDR.INS, EX-99.L SDR.INS | xbrli:xbrl |
Schema | EX-100.SCH | EX-101.SCH, EX-99.K SDR.SCH, EX-99.L SDR.SCH | xsd:schema |
Calculation Linkbase | EX-100.CAL | EX-101.CAL, EX-99.K SDR.CAL, EX-99.L SDR.CAL | link:linkbase | link:calculationLink
Definition Linkbase | EX-100.PRE | EX-101.PRE, EX-99.K SDR.PRE, EX-99.L SDR.PRE | link:linkbase | link:definitionLink
Label Linkbase | EX-100.LAB | EX-101.LAB, EX-99.K SDR.LAB, EX-99.L SDR.LAB | link:linkbase | link:labelLink
Presentation Linkbase | EX-100.PRE | EX-101.PRE, EX-99.K SDR.PRE, EX-99.L SDR.PRE | link:linkbase | link:presentationLink
Reference Linkbase | EX-100.REF | EX-101.REF | link:linkbase | link:referenceLink
Note: Although the Reference Linkbase file is a valid attachment type, at the moment it is not used. REMARK: Variation 001ng cannot be tested without the edgarSubmission XML document. REMARK: This test is continued at ../../902-sdr/60302-sdr-doctype/ | 6-5
## 6.3.3 | ## XBRL document names must match {base}-{date}[_{suffix}].{extension}.
XBRL Document | Documentname Format
--- | ---
Instance | {base}-{date}.xml
Schema | {base}-{date}.xsd
Calculation Linkbase | {base}-{date}_cal.xml
Definition Linkbase | {base}-{date}_def.xml
Label Linkbase | {base}-{date}_lab.xml
Presentation Linkbase | {base}-{date}_pre.xml
Reference Linkbase | {base}-{date}_ref.xml
Note:Although the Reference Linkbase file is a valid attachment type, at the moment it is not used. The {base} should begin with the registrant’s ticker symbol or other mnemonic abbreviation. The {date} must denote the ending date of the period. If the instance document is a prospectus or other report whose period is indefinite, {date} should match the filing date. For example, a Form 10-Q covering the period ending September 30, 2009 has {date} = 20090930; and a 485BPOS filed on January 23, 2010 has {date} = 20100123. The {base} should be the same as that used for the instance in the same submission. The {date} should be the same as that of the instance, even if the content of the schema is identical to some other schema, as for example if the same schema had been used in a previous quarterly filing. The {base} and {date} should be the same as that used for the instance in the same submission. REMARK: File names are case sensitive, and since January 2011, uppercase characters have been permitted. | 6-6
## 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-6
## 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-20111231.xml and e60305002ng-20111231_lab.xml are not even good XML, so don't try to process them as such. REMARK: this testcase is also a convenient place to test compliance with EFM section 5.2 listing a few common but disallowed characters. | 6-6
## 6.3.6 | ## The URI content of the xlink:href attribute, the xsi:schemaLocation attribute and the schemaLocation attribute, must be relative and contain no forward slashes, or a recognized external location of a standard taxonomy schema file, or a "#" followed by a shorthand xpointer. The xlink:href attribute must appear on the link:loc element; the schemaLocation attribute must appear on the xsd:import element, and the xsi:schemaLocation attribute must appear on the link:linkbase element and may appear on the xbrli:xbrl element. Valid entries for the xlink:href attribute, the xsi:schemaLocation attribute and the schemaLocation attribute are document locations. If they are relative URIs, they are subject to EDGAR attachment naming conventions. Therefore, all documents attached to the submission will be at the same level of folder hierarchy. By restricting the content of these attributes, all documents in the DTS of an instance will be either a standard taxonomy or present in the submission. Examples: xlink:href="abccorp-20100123.xsd" <xsd:import schemaLocation="http://xbrl.org/2006/xbrldi-2006.xsd" namespace="..."/> Counterexamples: xlink:href="http://www.example.com/2007/example.xsd" xlink:href="#element(1/4)" (Comment: this is a scheme-based xpointer, not shorthand) The XHTML namespace is intentionally omitted, since an XHTML declaration could not be a valid target for any XBRL element's xlink:href or schemaLocation attribute, and its presence in the xsi:schemaLocation attribute would not impact XBRL validation. There are dozens of other XBRL US GAAP Taxonomies documents to be used as templates to copy from during the preparation process, but their inclusion in an EDGAR filing tends to load unused linkbases and therefore introduces unwarranted complications such as unused extended links and a need for many prohibiting arcs. Reducing the amount of content in the DTS of the instance to its essentials frees users to more easily link the submitted documents to the linkbases of their particular interest for analysis. REMARK: xml:base is forbidden. REMARK:RFC 2396defines URI syntax | 6-7
## 6.3.8 | ## A submission must contain exactly one EX-100.INS or EX-101.INS or EX-99.K SDR.INS. An XBRL instance submitted in the Voluntary Filing Program may be an EX-100.INS. An Interactive Data instance in XBRL format must be an EX-101.INS, EX-99.K SDR.INS, or EX 99.L SDR.INS. REMARK: The EDGAR submission system has an Exhibit type and this is passed into the validator. | 6-7
## 6.3.10 | ## A submission must contain at least one company extension schema EX-100.SCH, 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-7
## 6.3.11 | ## Attribute xml:base must not appear in any Interactive Data document. XML processors interpret this attribute differently, so it must not be used. | 6-7
## 6.4.3 | ## The XBRL instance documents in a submission must be XBRL 2.1 valid. REMARK: XBRL 1.0 Dimensional validity is required also. 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. | 6-8
## 6.4.3 | ## The XBRL instance documents in a submission must be XBRL 2.1 valid. REMARK: XBRL 1.0 Dimensional validity is exercised in this suite.
Constant Feature of Taxonomy | Value
--- | ---
Dimensions | 30
Defaults | 30, so every dimension has one default
Line Items | 1 abstract, 28 durations, 1 instant.
Constant Instance Feature | Value
Periods | 10, non overlapping.
Units | Not applicable, all facts are Strings.
Parameterizable Instance Feature | Value
Number of dimensions (axes) used in facts | From 0 to 30
Possible non-default members per dimension (axis) | From 1 to 29
Facts | 5 DEI facts plus any number of dimensional facts, for example 10,000.
Dimensionally invalid facts | Current generator only supports 0
Overlapping periods and instants | Current generator only supports 0
Duplicate contexts | Generator does not track, but variation does indicate whether they exist
| 6-8
## 6.5.1 | ## The scheme attribute of the xbrli:identifier element must be http://www.sec.gov/CIK. | 6-8
## 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. REMARK: Variations 001ng and 002ng may produce error 60523 depending on implementation. | 6-8
## 6.5.3 | ## All xbrli:identifier elements in an instance must have identical content. REMARK: this will inevitably generate two errors . | 6-9
## 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-9
## 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-9
## 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-9
## 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. REMARK: 6.5.9 applies to context start dates compared against context end dates, irrespective of segments. | 6-10
## 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, 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) wherenis 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-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-11
## 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-11
## 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. REMARK: In XML it is vital to distinguish the DOM from its various serializations. For a text block, the DOM node starts as an element with one child text node; exactly one. It is that child text node that you now treat as a string, wrap <body> and </body> around it, then re-parse and validate against edbody.dtd; the grammar for the % Flow entity is clear. REMARK: By contrast, the content of a footnote according to XBRL 2.1 is any alternating sequence of text nodes and element nodes drawn with names in the xhtml namespace. The serialization does not (and cannot) matter. The additional constraint on footnotes imposed by EDGAR is that a footnote cannot just contain any old sequence of text and element DOM nodes. It has to be a sequence of DOM nodes that would be valid if they were the children of a body node instead. You do not read the footnote as a text node (that might have ampersands and angle brackets), as if it were itself a serialization. You take that sequence of DOM nodes, make them the children of a <body> node and validate. REMARK: Only restrictions of the textBlockItemType are relevant because the base type xbrli:stringItemType is declared final in the XBRL 2.1 schema and cannot be extended. | 6-11
## 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. REMARK: Restrictions on the content of href are documented in EFM 5.2.2.1. There is a DTD (edbody.dtd in the "lib" folder) used for validation of unescaped content, but a change to Schema (and therefore disallowing named entities) may occur at some time in the future. The DTD by itself does NOT check for nested <table> elements, but they are disallowed, as variation _030ng shows. 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/> <style/> <textarea/> REMARK: Variations 018 through 022 require http://www.xbrl.org/dtr/type/nonNumeric-2010-12-16.xsd in edgartaxonomies.xml | 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 Form 10-Q filings for a company with a June 30, 2009 fiscal year end as follows:
Quarter | xbrli:startDate | xbrli:endDate
--- | --- | ---
1 | 2009-07-01 | 2009-09-30
2 | 2009-07-01 | 2009-12-31
3 | 2009-07-01 | 2010-03-31
Many submissions require a second Required Context, see 6.5.21 below. Required contexts are distinguished by having no xbrli:segment elements. REMARK: The absence of required context will cause several other errors in section 6.5, this has a separate error code to help users identify the root error of the cascade. 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 this will be extended to include columns that indicate the allowable range of durations, for example:
Forms | Shortest | Typical
--- | --- | ---
485BPOS, 497 | P1D | P1D
10-K, 10-K/A, 10-KT, F-1, F-3, F-4, F-9, F-10, S-1, S-3, S-4, S-11, N-CSR, N-CSR/A | P1D | P1Y
10-Q, 10-Q/A, 10-QT, N-Q | P1D | P9M
N-CSRS, N-CSRS/A | P1D | P6M
| 6-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, S-1, S-11, S-3, S-4, POS AM , 10-KT, 10-QT, 10/A, 10-K/A, 10-Q/A, 20-F/A, 40-F/A, 6-K/A, 8-K/A, F-1/A, F-10/A, F-3/A, F-4/A, S-1/A, S-11/A, S-3/A, S-4/A, 10-KT/A, 10-QT/A EDGAR Form Types (Investment Management): 485BPOS, 497 , N-CSR, N-CSRS, N-Q, N-CSR-CSRS/A, N-Q EDGAR Exhibit Types (Trading & Markets): K SDR, L SDR | 8-K 485BPOS
dei:DocumentPeriodEndDate | CCYY-MM-DD | 2009-09-30
dei:AmendmentFlag | xsd:Boolean | true
dei:AmendmentDescription (present if and only if dei:AmendmentFlag equals 'true') | xsd:normalizedString | Correct the company HQ address
CCYY-MM-DD is an ISO 8601 format date. ISO 8601 is the international standard for representing dates, times, durations and periods issued by the International Standards Organization. Other elements in the "dei" namespace whose names start with "Document" are optional. REMARK: There is a mapping from submission types recognized by EDGAR, to the valid values of the dei:DocumentType element, as follows. From the 2012 DEI schema onward, all of the document type values shown are allowed; in earlier schemas you may find that the less common filing types must use other values:
EDGAR Submission Type: | DEI DocumentType Values:
"10-12B" | "10-12B", "Other"
"10-12B/A" | "10-12B/A", "Other"
"10-12G" | "10-12G", "Other"
"10-12G/A" | "10-12G/A", "Other"
"10-K" | "10-K"
"10-K/A" | "10-K", "10-K/A"
"10-KT" | "10-KT", "10-K", "Other"
"10-KT/A" | "10-KT/A", "10-K", "Other", "10-KT"
"10-Q" | "10-Q"
"10-Q/A" | "10-Q/A", "10-Q"
"10-QT" | "10-QT", "10-Q", "Other"
"10-QT/A" | "10-QT/A", "10-Q", "Other", "10-QT"
"20-F" | "20-F"
"20-F/A" | "20-F/A", "20-F"
"20FR12B" | "20FR12B", "Other"
"20FR12B/A" | "20FR12B/A", "Other"
"20FR12G" | "20FR12G", "Other"
"20FR12G/A" | "20FR12G/A", "Other"
"40-F" | "40-F"
"40-F/A" | "40-F/A", "40-F"
"40FR12B" | "40FR12B", "Other"
"40FR12B/A" | "40FR12B/A", "Other"
"40FR12G" | "40FR12G", "Other"
"40FR12G/A" | "40FR12G/A", "Other"
"485BPOS" | "485BPOS"
"497" | "497", "Other"
"6-K" | "6-K"
"6-K/A" | "6-K/A", "6-K"
"8-K" | "8-K"
"8-K/A" | "8-K/A", "8-K"
"8-K12B" | "8-K12B", "Other"
"8-K12B/A" | "8-K12B/A", "Other"
"8-K12G3" | "8-K12G3", "Other"
"8-K12G3/A" | "8-K12G3/A", "Other"
"8-K15D5" | "8-K15D5", "Other"
"8-K15D5/A" | "8-K15D5/A", "Other"
"F-1" | "F-1"
"F-1/A" | "F-1/A", "F-1"
"F-10" | "F-10"
"F-10/A" | "F-10/A", "F-10"
"F-10EF" | "F-10EF", "Other"
"F-10POS" | "F-10POS", "Other"
"F-1MEF" | "F-1MEF"
"F-3" | "F-3"
"F-3/A" | "F-3/A", "F-3"
"F-3ASR" | "F-3ASR", "F-3"
"F-3D" | "F-3D", "F-3"
"F-3DPOS" | "F-3DPOS", "F-3"
"F-3MEF" | "F-3MEF"
"F-4" | "F-4"
"F-4 POS" | "F-4 POS", "F-4"
"F-4/A" | "F-4/A", "F-4"
"F-4EF" | "F-4EF", "F-4"
"F-4MEF" | "F-4MEF"
"N-CSR" | "N-CSR"
"N-CSR/A" | "N-CSR/A"
"N-CSRS" | "N-CSRS"
"N-CSRS/A" | "N-CSRS/A"
"N-Q" | "N-Q"
"N-Q/A" | "N-Q/A"
"POS AM" | "F-1", "F-3", "F-4", "F-6", "S-1", "S-3", "S-4", "S-11", "POS AM", "Other"
"POS EX" | "F-3", "F-4", "S-1", "S-3", "S-4", "POS EX", "Other"
"POSASR" | "F-3", "S-3", "POSASR", "Other"
"S-1" | "S-1"
"S-1/A" | "S-1/A", "S-1"
"S-1MEF" | "S-1MEF"
"S-11" | "S-11"
"S-11/A" | "S-11/A"
"S-11MEF" | "S-11MEF"
"S-3" | "S-3"
"S-3/A" | "S-3/A", "S-3"
"S-3ASR" | "S-3ASR", "S-3"
"S-3D" | "S-3D", "S-3"
"S-3DPOS" | "S-3DPOS", "S-3"
"S-3MEF" | "S-3MEF"
"S-4" | "S-4"
"S-4 POS" | "S-4 POS", "S-4"
"S-4/A" | "S-4/A", "S-4"
"S-4EF" | "S-4EF", "S-4"
"S-4MEF" | "S-4MEF"
"SP 15D2" | "SP 15D2"
"SP 15D2/A" | "SP 15D2/A"
| 6-13
## 6.5.21 | ## An instance must contain one non-empty fact for each required Entity Information element, each with a contextRef attribute referring to a Required Context. The value of an EntityPublicFloat fact in an instance will be 0 for an entity that has only public debt. Required Entity Information facts may specify attribute xml:lang, but facts with xml:lang attribute absent or xml:lang equal to "en-US" take precedence over facts having other values for xml:lang. Required Entity Information facts having period type "instant" use a context containing an xbrli:instant value that is the measurement date (for public float and common shares or other units of ownership outstanding), otherwise identical to the Required Context. Additional facts using the Required Entity Information elements are allowed in other contexts. The table below contains a description of the elements along with their base type, as well as providing an example for each.
Element | Base Type | (Example)
--- | --- | ---
EntityRegistrantName | xsd:normalizedString | General Example Company
EntityCentralIndexKey | us-types:centralIndexKey | 0005551212
EntityCurrentReportingStatus | us-types:yesNo | Yes
EntityVoluntaryFilers | us-types:yesNo | No
CurrentFiscalYearEndDate | xbrli:gMonthDayItemType | --12-31*
EntityFilerCategory | us-types:filerCategory | Large Accelerated Filer
EntityWellKnownSeasonedIssuer | us-types:yesNo | Yes
EntityPublicFloat | xsd:decimal | 9876543210
DocumentFiscalYearFocus | xbrli:gYearItemType | 2009**
DocumentFiscalPeriodFocus | us-types:fiscalPeriodItemType | FY, Q1, Q2, Q3, Q4, H1, H2, M9, T1, T2, T3, M8, CY
*Note: The value space of xbrli:gMonthDayItemType is in the format --MM-DD. **Note: The value space of xsd:gYearItemType is a year in the form CCYY. ***Note: 10-Q‟s for the 1st, 2nd and 3rd quarters should have a fiscal period focus of Q1, Q2, and Q3 respectively, and a 10-K should have fiscal period focus of FY. The following table shows which elements will be validated for each form type. Please note, however, that omitting the Registrant Name or Central Index Key leads to other errors, but otherwise, omission of data within the XBRL tags for these elements will not result in the suspension of the filing nor will the XBRL data be removed. Instead, a warning message will be added to the filer's acceptance message if the data is not included or does not match the base type as specified in the table above. All other Entity Information elements are optional (see 6.5.22).
Element | 10-K, 10-KT | 10-Q, 10-QT | SDR-K, SDR-L | 20-F | 40-F | 6-K, N-CSR, N-Q, N-CSRS | 10, S-1, S-3, S-4, S-11, POS AM | 8-K, F-1, F-3, F-10, 497, 485BPOS
--- | --- | --- | --- | --- | --- | --- | --- | ---
EntityRegistrantName | X | X | X | X | X | X | X | X
EntityCentralIndexKey | X | X | X | X | X | X | X | X
EntityCurrentReportingStatus | X |  |  | X | X |  |  |
EntityVoluntaryFilers | X |  |  |  |  |  |  |
CurrentFiscalYearEndDate | X | X | X | X | X | X |  |
EntityFilerCategory | X | X |  | X |  |  | X |
EntityWellKnownSeasonedIssuer | X |  |  | X |  |  |  |
EntityPublicFloat | X |  |  |  |  |  |  |
DocumentFiscalYearFocus | X | X | X | X | X | X |  |
DocumentFiscalPeriodFocus | X | X | X | X | X | X |  |
| 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-16
## 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-16
## 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. REMARK: The syntax of the cikList is comma separated 10-digit numbers [0-9]{10}(,[0-9]{10})* REMARK: The syntax of the cikNameList is "|Edgar|" separated text (.)+(\|Edgar\|,(.)+) REMARK: Continued at902-sdr-60524 | 6-16
## 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. REMARK: Only restrictions of the type are relevant because the base type xbrli:stringItemType is declared final in the XBRL 2.1 schema and cannot be extended. | 6-16
## 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. REMARK: The rule does not strictly require definition links, only that the contexts use xbrli:explicitMember elements in contexts.
[Variant] | [Form Type] | [Facts in Req Context] | [Facts with Share Class] | [Extra Facts] | [IFRS] | [Links] | [Result]
--- | --- | --- | --- | --- | --- | --- | ---
000 | 10-K | 0 | 0 | 0 | 0 | true | gw
001 | 10-K | 0 | 0 | 1 | 0 | true | gw
002 | 10-K | 0 | 1 | 0 | 0 | true | gw
003 | 10-K | 0 | 1 | 1 | 0 | true | gw
004 | 10-K | 0 | 2 | 0 | 0 | true | gd
005 | 10-K | 0 | 2 | 1 | 0 | true | gd
006 | 10-K | 1 | 0 | 0 | 0 | true | gd
007 | 10-K | 1 | 0 | 1 | 0 | true | gd
008 | 10-K | 1 | 1 | 0 | 0 | true | gw
009 | 10-K | 1 | 1 | 1 | 0 | true | gw
010 | 10-K | 1 | 2 | 0 | 0 | true | gw
011 | 10-K | 1 | 2 | 1 | 0 | true | gw
012 | 10-Q | 0 | 0 | 0 | 0 | true | gw
013 | 20-F | 0 | 0 | 0 | 0 | true | gw
014 | 20-F | 0 | 1 | 0 | 0 | true | gw
015 | 20-F | 0 | 2 | 0 | 0 | true | gd
016 | 20-F | 1 | 0 | 0 | 0 | true | gd
017 | 20-F | 1 | 1 | 0 | 0 | true | gw
018 | 20-F | 1 | 2 | 0 | 0 | true | gw
019 | 40-F | 0 | 0 | 0 | 0 | true | gw
020 | N-Q | 0 | 0 | 0 | 0 | true | gd
021 | 8-K | 0 | 0 | 0 | 0 | true | gd
022 | 6-K | 0 | 0 | 0 | 0 | true | gd
023 | N-CSR | 0 | 0 | 0 | 0 | true | gd
024 | 485BPOS | 0 | 0 | 0 | 0 | true | gd
025 | 497 | 0 | 0 | 0 | 0 | true | gd
026 | 10-KT | 0 | 0 | 0 | 0 | true | gw
027 | 10-QT | 0 | 0 | 0 | 0 | true | gw
028 | 10-K | 0 | 0 | 0 | 0 | false | gw
029 | 10-K | 0 | 0 | 1 | 0 | false | gw
030 | 10-K | 0 | 1 | 0 | 0 | false | gw
031 | 10-K | 0 | 1 | 1 | 0 | false | gw
032 | 10-K | 0 | 2 | 0 | 0 | false | gd
033 | 10-K | 0 | 2 | 1 | 0 | false | gd
034 | 10-K | 1 | 0 | 0 | 0 | false | gd
035 | 10-K | 1 | 0 | 1 | 0 | false | gd
036 | 10-K | 1 | 1 | 0 | 0 | false | gw
037 | 10-K | 1 | 1 | 1 | 0 | false | gw
038 | 10-K | 1 | 2 | 0 | 0 | false | gw
039 | 10-K | 1 | 2 | 1 | 0 | false | gw
040 | 10-Q | 0 | 0 | 0 | 0 | false | gw
041 | 20-F | 0 | 0 | 0 | 0 | false | gw
042 | 20-F | 0 | 0 | 0 | 1 | false | gw
043 | 20-F | 0 | 1 | 0 | 0 | false | gw
044 | 20-F | 0 | 1 | 0 | 1 | false | gw
045 | 20-F | 0 | 2 | 0 | 0 | false | gd
046 | 20-F | 0 | 2 | 0 | 1 | false | gd
047 | 20-F | 1 | 0 | 0 | 0 | false | gd
048 | 20-F | 1 | 0 | 0 | 1 | false | gd
049 | 20-F | 1 | 1 | 0 | 0 | false | gw
050 | 20-F | 1 | 1 | 0 | 1 | false | gw
051 | 20-F | 1 | 2 | 0 | 0 | false | gw
052 | 20-F | 1 | 2 | 0 | 1 | false | gw
053 | 40-F | 0 | 0 | 0 | 0 | false | gw
054 | 40-F | 0 | 0 | 0 | 1 | false | gw
055 | N-Q | 0 | 0 | 0 | 0 | false | gd
056 | 8-K | 0 | 0 | 0 | 0 | false | gd
057 | 6-K | 0 | 0 | 0 | 0 | false | gd
058 | 6-K | 0 | 0 | 0 | 1 | false | gd
059 | N-CSR | 0 | 0 | 0 | 0 | false | gd
060 | 485BPOS | 0 | 0 | 0 | 0 | false | gd
061 | 497 | 0 | 0 | 0 | 0 | false | gd
062 | 10-KT | 0 | 0 | 0 | 0 | false | gw
063 | 10-QT | 0 | 0 | 0 | 0 | false | gw
| 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. In particular, the schema fales of the ng variations should throw error 6.7.27 because they use a substitutionGroup disallowed by that rule; the point being that 6.7.27 would not apply to a standard taxonomy but 6.5.27 would still be an error. 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-17
## 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. These variations may also signal errors 6.9.4 and 6.9.5 for the schemas, or 6.8.3, but the point is that this test is still meaningful even if the schemas with offending role declarations happened to be in standard taxonomies. | 6-17
## 6.5.29 | ## The xlink:role attribute of a link:loc element must be empty, or defined in the XBRL Specification 2.1. | 6-17
## 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-17
## 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-17
## 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. REMARK: XBRL footnotes are not text blocks. Any quoted HTML appearing in an XBRL footnote is just a string. All processing should treat it as a string and nothing more. | 6-17
## 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 athttp://www.sec.gov/edgar/info/edgartaxonomies.shtml.
Type name-space | Type element name | Unit measure name-space | Unit measure element names | Meaning | Unit numerator name-space | Unit numerator element name | Unit denominator namespace | Unit denominator element name
--- | --- | --- | --- | --- | --- | --- | --- | ---
(any) | percentItemType | xbrli | pure |  | n/a | disallowed | n/a | disallowed
(any) | perShareItemType | n/a | disallowed |  | iso4217 | 3-letter ISO4217 codes | xbrli | shares
(any) | areaItemType | (any) | sqft | Square Foot | n/a | disallowed | n/a | disallowed
sqyd | Square Yard
sqmi | Square Mile
A | Acre
sqm | Square Meter
sqkm | Square Km
sqemi | Square English Mile
(any) | volumeItemType | (any) | l | Liter | n/a | disallowed | n/a | disallowed
m3 | Cubic Meter
ft3 | Cubic Foot
gal | Gallon
cf | Cubic Feet of Natural Gas at 14.73psi and 60 degrees F
Mcf | Thousands of Cubic Feet of Natural Gas at 14.73psi and 60 degrees F
MMcf | Millions of Cubic Feet of Natural Gas at 14.73psi and 60 degrees F
bbl | Barrels of Oil at 60 degrees F
MBbls | Thousands of Barrels of Oil at 60 degrees F
MMbbls | Millions of Barrels of Oil at 60 degrees F
In this table, for example, facts whose type is based on areaItemType must have a unit whose measure is one of sqft, sqyd, sqmi, etc. The notation "(any)" means that the element namespace is ignored for the purposes of checking for consistency. | 6-17
## 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. REMARK: the unit "u 100 twobyte 1 onebyte" means there is a measure whose local name consists of 100 two-byte unicode characters and one single-byte character. | 6-19
## 6.5.37 | ## The decimals attribute value must not cause non-zero digits in the fact value to be interpreted as zero. If the decimals attribute of a numeric fact is not equal to 'INF', then the value is interpreted as if certain digits were zero. Interactive Data documents must not contain usage that results in such truncations. The examples below illustrate correct and incorrect use:
Fact text | Decimals value | Interpreted value | Result
--- | --- | --- | ---
-2345.67 | INF | -2,345.67 |
-2345.67 | 2 | -2,345.67 |
-2345.67 | 0 | -2,345.00 | Error
-2345.67 | -2 | -2,300.00 | Error
-2345.67 | -3 | -2000.00 | Error
-2345.67 | -6 | 0000.00 | Error
For further information and guidance using the decimals attribute, see 6.6.32 below. | 6-19
## 6.5.38 | ## Do not use the forever period in contexts. | 6-19
## 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-19
## 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: 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. 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. 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. 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. 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. If a submission has a emergingGrowthCompanyFlag and there is an EntityEmergingGrowthCompany element in the dei namespace in the DTS of the instance, then the required context should have a dei: EntityEmergingGrowthCompany fact with a value that agrees. If the header does not have an emergingGrowthCompanyFlag then the required context should not contain such a fact. 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. 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. 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 valuenotcontaining 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". 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". 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". 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". 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-18
## 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-20
## 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-20
## 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