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.

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

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

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

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

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

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

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

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

REMARK: File names are case sensitive, and since January 2011, uppercase characters have been permitted.

6.3.4

An XBRL document must not contain HTML character name references.

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

REMARK: This test suite does NOT test to see that only the subset of ASCII allowed by 5.2.1.1 are used.

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

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

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

6.4.3

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

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

6.5.1

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

6.5.2

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

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

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

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

REMARK: Variations 001ng and 002ng may produce error 60523 depending on implementation.

6.5.3

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

REMARK: this will inevitably generate two errors

6.5.4

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

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

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

An instance must not contain duplicate xbrli:context elements.

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

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

The table shows examples of this usage.

6.5.8

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

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

6.5.9

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

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

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

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

REMARK: 6.5.9 applies to context start dates compared against context end dates, irrespective of segments.

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

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

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

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

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

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

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

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

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

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

6.5.15

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

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

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

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

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

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 lt;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.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/> <span/> <style/> <tbody/> <textarea/> <tfoot/> <thead/>

REMARK: Variations 018 through 022 require http://www.xbrl.org/dtr/type/nonNumeric-2010-12-16.xsd in edgartaxonomies.xml

6.5.17

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

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

6.5.19

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

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

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

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:

6.5.20

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

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

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

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:

6.5.21

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

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

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

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

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

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

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

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

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

6.5.22

All other elements in the dei namespace are optional.

REMARK: The second variation is logically part of 6.5.20, but it generates no errors so that shouldn't matter.

6.5.23

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

6.5.24

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

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

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

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

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

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

6.5.32

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

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

6.5.33

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

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

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

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

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.

REMARK: International types declared at www.xbrl.org can appear in the same DTS with US data types.

REMARK: The example values in the table above may not be completely consistent with any specific Unit Types Registry.

REMARK: The triggering condition of "element UTR present in a standard namespace" is present in the DEI 2012 taxonomy, but not in any prior version of DEI.

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

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

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

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

6.5.38

Do not use the forever period in contexts.

6.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.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: For purposes of this testedgartaxonomies.xmlis the authoritative source of "standard taxonomies".

6.7.4

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

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

6.7.6

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

Examples:

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

Counterexamples:

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

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

6.7.7

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

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.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.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.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 each individual schema which is what the similar XBRL 2.1 constraint applies to.

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.

REMARK: this applies only to company extension schemas, so that exceptions in the us-roles-YYYY-MM-DD.xsd schemas are not invalid.

6.7.12

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

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

{SortCode} - {Type} - {Title}

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

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

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

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

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

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

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

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.

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.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.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.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: For purposes of this test, the copy of edgartaxonomies.xml in the "lib" folder defines "standard taxonomy".

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.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 is only meant to apply to element declarations in an xbrli substitution group. In the current EDGAR release, non-XBRL element declarations are effectively useless, but nevertheless variation 000gd tests that case.

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 happens to hold for all standard taxonomies. At one time ICI 2006 was the basis of other variations, but it now has been removed from edgartaxonomies.xml, so there are no such variations.

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

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

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

REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies.

REMARK: The original wording required a specific US type, not a type derived from it. Now, types in any standard namespace can trigger this rule. 006gd flips to 006ng as a consequence.

6.7.28

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

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

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

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

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

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

REMARK: the phrase "u100twobyte1onebyte" means there is a local name that consists of 100 two-byte unicode characters and one single-byte character.

6.7.30

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

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

6.7.31

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

6.7.32

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

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

REMARK: Element declarations that are abstract must have period type 'duration' due to 6.7.21, and declarations derived from domainItemType must have period type 'duration' whether abstract or not due to 6.7.28. This validation covers all other non numeric types.

REMARK: The nonnumeric base types are:

xbrli:anyURIItemType

xbrli:base64BinaryItemType

xbrli:booleanItemType

xbrli:dateItemType

xbrli:dateTimeItemType

xbrli:durationItemType

xbrli:gDayItemType

xbrli:gMonthDayItemType

xbrli:gMonthItemType

xbrli:gYearItemType

xbrli:gYearMonthItemType

xbrli:hexBinaryItemType

xbrli:languageItemType

xbrli:NameItemType

xbrli:NCNameItemType

xbrli:normalizedStringItemType

xbrli:QNameItemType

xbrli:stringItemType

xbrli:timeItemType

nonnum:escapedItemType

dei:yesNoItemType

xbrli:stringType

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 submissionmaycause an arc in a standard taxonomy to become ineffective.

REMARK: The text of EFM v22 fails to capture all intended cases and will be expanded as follows in a subsequent release:

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

Examples:

• An arc with use="prohibited" in a submissionmayprohibit an arc in a standard taxonomy.
• An arc with use="prohibited" with no equivalent arc is ineffectual.
• An arc with use="prohibited" with the priority attribute less than the priority attribute of an effective arc is ineffectual.
• An arc with use="optional" in a submission that is prohibited is ineffectual.
• An arc with use="optional" in a submission maynotbe equivalent to an unprohibited arc in a standard taxonomy.

6.9.4

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

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. Also note that this only applies to a company extension linkbase.

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.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.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.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 and 2012 standard taxonomy linkbases contain links with priority attributes of 10, and rr 2012 is therefore a 'good' test variation.

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.

REMARK: The xlink:role value on the LabelLink element is not relevant.

REMARK: Also, case 015ng and 016ng will cause a 6.10.13 error as well as a 6.10.1 error.

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.

REMARK: the value of xlink:role on the LabelLink is not relevant.

6.10.3

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

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

6.10.4

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

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

REMARK: this restriction applies to all elements, not just those used in the instance.

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

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

6.12.1

The link:presentationArc element requires an order attribute.

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

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

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

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

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

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

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

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

6.12.5

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

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

6.12.6

Each effective presentation relationship base set should have only one root element.

An element that appears in a presentation base set only as a source and never as a target is a root element of that base set. The root element is normally abstract, but need not be (6.13.3).

6.12.7

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

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

6.12.8

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

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

REMARK: This isnotthe same condition as implemented in rendering engine 3.3.0.814, but it is logically sound.

6.12.9

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

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

6.14.1

Element link:calculationArc requires an order attribute.

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

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

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

6.16.1

Element link:definitionArc requires an order attribute.

This ensures an intentional displayed order of definition relationships.

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

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

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

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

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

REMARK: DRS discovery begins at dimension-domain relationships. Whether the domain member appears in instance facts is not relevant.

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.

REMARK: This only applies to company extension linkbases. Because the standard linkbases now all have priority 10 on their definition arcs, there is no way to prohibit them and so that variation of the test is not included here.

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.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.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.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.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.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.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'. For purposes of this testedgartaxonomies.xmlis the ONLY authoritative source of "standard taxonomies". This test checks 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.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.

REMARK: Test variations that reference disallowed versions of the DEI schema may produce downstream errors as a consequence of the unloadable schema and elements in that dei namespace being undefined.

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 were originally meant only 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). Eventually, taxonomies of different vintages are expected to coexist in a DTS without XBRL-level errors and this testcase will not be necessary. In the meantime and until further notice, other filing considerations mean that some taxonomies remain incompatible as listed below. Linkbase versions are only relevant insofar as there are schemas that would appear in the DTS as a consequence of processing that linkbase.

6.22.4

Supported Versions of XBRL Standard Taxonomies.

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

REMARK: There is no such section 6.22.4, it is only here to make sure that ex-101's are validated for every taxonomy.

6.26.1

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

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

6.26.2

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

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

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

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

6.26.3

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

An effective presentation relationship base set that is recognized as representing a statement of changes is a table with sets of rows having alternating instant and duration-type elements (6.24.10). The special layout is not needed unless there is at least one duration-type fact that represents the change in value from one instant to another, even if it is a nil-valued fact used as a placeholder.

6.26.4

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

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

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

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

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

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

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

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

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

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

6.26.5

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

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

6.26.6

An embedding command and the effective presentation relationship base set designated by its role URI should together provide an ordering of row axes and column axes for all facts it displays.

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

REMARK: When triggered, this warning is preceded by 6.12.06-Multiple-Root-Nodes warning because without the axis in the presentation group, no facts with that axis would appear at all.

6.26.7

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

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

6.26.8

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

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

6.26.9

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

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