REMARK: This cannot be tested outside of the EDGAR system itself.

REMARK: On variation 002, EdgarLink software already tests for this condition so it is unlikely this could ever come about; it is here in the suite for internal testing.

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

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: xml:base is forbidden.

REMARK: RFC 2396 defines URI syntax

REMARK: This cannot be tested independently of the EDGAR submission system.

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.

REMARK: Variation 009gd assumes there is no units registry yet implemented.

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

REMARK: this will inevitably generate two errors

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

REMARK: this applies to all pairs of duration and instant contexts. It is not necessary to test a context's start and end dates against itself because XBR2.1 section 4.7.2 requires that startDate is strictly less than end date.

REMARK: Some of these variations will be disallowed under 6.6.35 after a UTR is implemented.

REMARK: Abbreviations are from Base Units

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.

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. See 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: Restrictions on the content of href are documented in EFM 5.2.2.1. There is a DTD used for validation of unescaped content, but a change to Schema (and therefore disallowing named entities) may occur at some time in the future.

REMARK: For reference only, here are tags forbidden, keeping in mind that all permitted tags are lower case: <acronym/> <applet/> <area/> <base/> <basefont/> <bdo/> <button/> <col/> <colgroup/> <del/> <fieldset/> <font/> <form/> <frame/> <frameset/> <iframe/> <input/> <ins/> <label/> <legend/> <map/> <meta http-equiv='name' content='content'/> <noframes/> <noscript/> <object/> <option/> <param/> <q/> <s/> <S/> <script/> <select/> <span/> <style/> <tbody/> <textarea/> <tfoot/> <thead/>

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

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 the ERXL table will be extended to include columns that indicate the allowable range of durations, for example:

REMARK: There is a mapping from submission types recognized by EDGAR, to the valid values of the dei:DocumentType element. The mapping (submissionType,documentType) is:

REMARK: This set of test cases reflects the variations for the forms 20-F, 40-F, 6-K, 8-K, 10-Q, 10-K, 10, S-1, S-3, S-4, S-11, F-1, F-3, F-10, 485BPOS, N-CSR, N-Q, NCSRS as well as, implicitly 20-F/A, 40-F/A, 10-K/A, S-1/A, S-3/A, S-4/A, S-11/A, F-1/A, F-3/A, F-10/A, N-CSR/A, N-Q/A, NCSRS/A, 485BPOS and 497. Here is what form requires what element:

REMARK: This test substitutes for 6.5.21's requirement for CommonStockSharesOutstanding but is not yet implemented as of EDGAR 10.4 (December 2010).

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.

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, but the point is that this test is still meaningful even if the schemas with offending role declarations happened to be in standard taxonomies.

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.

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

REMARK: As of EDGAR 10.4 this test had not been implemented. The values in the table above are not completely consistent with the forthcoming Unit Types Registry.

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.

REMARK: edgartaxonomies.xml is the ONLY authoritative source of "standard taxonomies".

REMARK: There is a mismatch between the date formats currently accepted by EDGAR, and the possible ISO8601 formats.

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.

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.

REMARK: http://www.ietf.org/rfc/rfc2396.txt notes 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.

REMARK: this applies to the entire DTS, not just the company schema which is what the similar XBRL 2.1 constraint applies to.

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

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

REMARK: This was never meant to apply to resource roles, and that will be corrected in a future release.

REMARK: Because the (incorrectly percieved) importance of instance rendering has continued to increase beyond reason, the validator now enforces an even more stringent criterion than documented in manual version v13. The regex is "[0-9]+ \- {Statement|Disclosure|Schedule|Document} \-.*[^\s]"; this discrepancy between the text of the manual and the actual validation MUST be corrected in the manual ASAP.

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.

REMARK: this applies to the entire DTS not just company extension schemas.

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.

REMARK: only http://www.sec.gov/info/edgar/edgartaxonomies.xml defines "standard taxonomy".

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 only applies to the company extension schemas. If there were a standard taxonomy schema that violated this, it would nevertheless be good. There being no such standard taxonomy, there is no such test variation.

REMARK: This was only meant to apply to element declarations in an xbrli substitution group. In the current EDGAR release, non-XBRL element declarations are effectively useless and if that were ever to change this rule should be changed and some new variations included.

REMARK: This only applies to company extension schemas, although it does hold for all standard taxonomies other than the ICI 2006 taxonomy. Hence the inclusion of a 'good' case 003gd that imports the ICI 2006 taxonomy. It is 'GOOD' with respect to this rule, but has dozens of violations of other EFM rules. ICI 2006 can only be used with EX-100 attachments that are not subject to Chapter 6 validations.

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.

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.

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.

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.

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.

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

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.

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.

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.

REMARK: This applies only to company extension taxonomies. The arc roles declared in http://www.xbrl.org/2005/xbrldt-2005.xsd are okay because that is a standard taxonomy location. The arc roles declared in US GAAP 2009 are not in a standard taxonomy location.

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.

REMARK: This only applies to a company extension linkbase. The RR 2010 standard taxonomy linkbase contains links with priority attributes of 10, and is therefore a 'good' test variation.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

REMARK: Should be "...single extended link role".

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.

REMARK: Note that it is not necessary for the target element to be used in the instance, for this to be a violation.

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

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. If a standard taxonomy linkbase appearing in edgartaxonomies.xml violated this rule it would be included in a 'good' test variation.

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

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.

REMARK: Consecutive relationships are defined at http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm#_2.1.1 and 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.

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.

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.

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 that http://www.sec.gov/info/edgar/edgartaxonomies.xml is the ONLY authoritative source of "standard taxonomies". In this test suite we test a subset of the disallowed files, one at a time.

REMARK: There is no such section 6.22.3, these tests are just to verify that 2008 taxonomies work together but do not work with the 2009 or subsequent taxonomies because of the XBRL 2.1 level conflict between roleType declarations (when their allowed linkbases are included in the mix). Going forward, taxonomies of different vintages are expected to coexist in a DTS without XBRL-level errors and this testcase will not be necessary.

REMARK: There is no such section 6.22.4, it is only here to make sure that ex-101's are validated even for SOI and RR taxonomies.