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-20081231.xml and e60305002ng-20081231_lab.xml are not even good XML, so don't try to process them as such.

REMARK: there are no 2009 taxonomy examples here because the focus is on href syntax.

REMARK: xml:base is forbidden.

REMARK: RFC 2396 defines URI syntax

REMARK: Only 2008 taxonomies are used in these tests, but that does not matter, it is a test of xml:base.

REMARK: This obviously does not test all XBRL 2.1, only those areas that have been known to cause problems.

REMARK: At this time, only one instance is allowed per submission.

REMARK: XBRL 1.0 Dimensional validity is required also.

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: 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: 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: 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: 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: 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: 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: 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. If there were a standard taxonomy that violated this, it would appear in a 'good' test variation.

REMARK: This is defined to require the type attribute to equal stringItemType. This means that domain items cannot be abstract. A future release might relax this rule so that elements of any type derived from 'string' could be abstract.

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 wording really does require that specific type, not a type derived from it - not sure it is worth changing, but for consistency, variation 006gd ensures that derived types are ignored.

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: This applies to company extension linkbases, but no standard taxonomy linkbase violates it.

REMARK: Note that type='extended' is handled by XBRL 2.1 so this really only applies to type='resource', and there are other rules for reference and footnote that would trigger errors if the xlink:role were missing. Therefore just one variation for the label resource, for now.

REMARK: This only applies to a company extension linkbase, and RR 2008 is a standard taxonomy, hence case 000gd.

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: This rule does not define where DRS discovery should begin. The interpretation of the constraint that is least likely to cause filing rejectin, and therefore the one used here, is that DRS discovery begins at each separate dimension-domain relationship. This may become more restrictive in a future release, so implementors may wish to consider issuing a warning in cases such as the complex situation in variation _006gd.

REMARK: The text "This rule also impacts line items, so that the balance at the start and end a roll forward cannot appear twice under a single axis" means that test case 007gd should have been 007ng. In the current EDGAR release, it is, and remains, 007gd. A future release will either strike this sentence from the rule OR change the testcase to 007ng.

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

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.