Staff Interpretations and FAQs Related to Interactive Data Disclosure

A: In all SEC submissions and attachments (other than Ex. 100 and Ex. 101), EDGAR rejects HTML that does not conform to a restriction of HTML 3.2 DTD, in particular rejecting anything that could pose a security threat to a recipient. On that general principle, the EDGAR Validator will analyze Interactive Data content that, when un-escaped, may be interpreted as HTML, and will reject it if it contains content that the existing DTD would reject. EDGAR Filer Manual Rules 6.5.15 and 6.5.16 address this currently. Note that Block Text content must also be well formed XML. This is a stronger requirement than validating against the EDGAR HTML 3.2 DTD.

A: An EDGAR filing can be accepted with ‘Warnings’ even if some of its attached exhibits have errors. Exhibits that have errors are stripped from the filing before it is accepted into EDGAR. XBRL files are exhibits. Therefore, an error message that looks like this “WRN: XBRL Error…” means that the XBRL files will be stripped from a live filing, but the rest of the filing will be accepted into EDGAR. If this happens the filer must submit an Amendment with the corrected XBRL.

A message that looks like this “WRN: XBRL Warning…” means that there is a minor error in the XBRL exhibit, but the XBRL file will not be stripped. We encourage filers to fix these errors in their subsequent filings. A message that looks like “ERR:” or “WRN:” but does not mention XBRL is not an XBRLproblem, and is due to some other aspect of the submission.

A: No. The older Voluntary Filing Program Data Viewers are separate from the Interactive Data Viewer and are currently not supported by the SEC.

A: Yes. If Interactive Data pursuant to the rules in Release No. 33-9002 is previewed using the Interactive Data Previewer, then the rendering will be the same.

A: There are some rules in the EDGAR Filer Manual oriented toward rendering. For example, EDGAR Filer Manual rule 6.7.12 explains how to order the pages to be rendered from a submission by manipulating the link:description element of link:roleType declarations, rule 6.13.4 describes how parentheticals should be arranged in the presentation linkbase, etc.

The personal renderer, which can be downloaded from http://www.sec.gov/spotlight/xbrl/renderingenginelicense.htm, contains a document with more detailed information about the personal renderer and how it works.

A: The conditions under which Inline XBRL may be accepted, and how the processing may be integrated into the EDGAR validation and the Interactive Data Viewer processes have not yet been determined.

A: The previewer does not test the validity of the filing; you must do this separately either by submitting it as an EDGAR test filing or using a commercial validation software product that tests filings against the Commission's rules. The previewer renders invalid filings as best it can, but may fail in a way that does not identify the root cause. Additionally, the previewer may produce results that “look” right, even if the filing has errors that could cause the XBRL to be removed from a live filing if submitted For these reasons, we encourage the use of a test filing prior to final submission.(See A.3).

A: For the most part, the viewer cannot render facts of different types on the same row.

The rendering engine does have the ability to render complex dimensional data layouts, including rows with a mix of data types, by “embedding” table layout commands into text blocks; this is described in the Risk/Return Rendering guide (see C.1).

A: It does not matter whether they render correctly in the previewer or not, the submission should be rejected by the Validator if facts use a mix of "en" and "en-US" labels. (See B.5).

A: Make sure that the embedded HTML appears inside of elements whose type is nonnum:textBlockItemType. It is not enough for the element name to end with "TextBlock". Different versions of the XBRL US GAAP Taxonomy may have more or less consistent element naming conventions, but it is the element type that is important, not the element name. See EFM 6.5.16 for examples of correct escaping.

A: EDGAR Filer Manual rule 6.13.1 states this requirement more precisely. The presentation relationships within a given role (for a statement, say) must be the same as the original ordering. Also, the indentation of real financial statements is much "flatter" than the deep nesting of a typical standard taxonomy, and the presentation linkbase should reflect that. Also, EDGAR Filer Manual rule 6.13.4 forces parentheticals out of the main statement roles, and into separate roles specifically for parentheticals.

This is why standard presentation linkbases are usually not in the list of taxonomies on the SEC website. Consider: the element order must match the order of the Original HTML/ASCII file. If a standard presentation linkbase (for a statement or a disclosure) were included in the DTS of an instance, then any change of order (due to a difference in materiality, for example) would require both a prohibiting relationship as well as the new label. In the case of the XBRL US GAAP Taxonomies 1.0 standard presentation linkbases, only a small percentage of those presentation relationships even in the smaller statements and disclosures are likely to be a match to the ordering of a filer's financial statements. The EDGAR Validator lets the filer construct the presentation order appropriate for the instance, and requires no other presentation relationships. A filer should expect their company presentation linkbase to change in some way with every new filing, though perhaps not as much as the instance and labels change.

A: The way to satisfy these rules is to use an abstract to be the parent of the text block, in each of the separate roles. For example,

And so on.

A: As noted in B.3 above, EFM section 6.7.12 describes the technical format of the presentation group “description” field, of which the “Title” is one part. While there is no requirement to follow a standard naming convention for the Title, we encourage filers to use the presentation group titles described below:

• Title Document and Entity Information "Document and Entity Information."
• Title Level I presentation groups in a manner consistent with the title of the financial statements and footnotes appearing in the original HTML/ASCII version. For example, a title for the balance sheet presentation group might be "Condensed Consolidated Balance Sheets," and a text-blocked footnote title might be "Commitments and Contingencies." Also, parenthetical disclosures should follow the naming convention of the financial statement to which they relate, such as, for example, "Condensed Consolidated Balance Sheets (Parenthetical)."
• Title Level II significant accounting policies as one presentation group titled "Official HTML/ASCII Documents' Note Label (Policies)," such as, for example, "Significant Accounting Policies Note (Policies)."
• Title Level III text-blocked tables "Official HTML/ASCII Documents' Note Label (Table)." We suggest that all Level III text-blocked tables relating to tables appearing within a single footnote in the original HTML/ASCII version be included in a single presentation group. For example, all tables appearing in the "Cash and Cash Equivalents" footnote would be in the presentation group titled, "Cash and Cash Equivalents (Tables)."
• Title Level IV detail tagged groups “Official HTML/ASCII Documents’ Note Label 1st Table Name (Details),” “Official HTML/ASCII Documents’ Note Label 2nd Table Name (Details),” and so forth.

Also, EFM section 6.7.9 defines the technical format of the presentation group’s ‘roleURI’ attribute which ends with a “mnemonic name in LC3 format”. It is not necessary for that mnemonic name to match the group title word-for-word.

A: The rendering engine has been updated to allow users to more easily navigate through the rendered interactive data. Hyperlinks to sections of the filing are now grouped under expandable standard headings. This navigation structure is based on the presentation group ordering currently in use by virtually all filers, so filers should not need to change their existing presentation group ordering to use this structure. Information is provided here to show the standard headings and give examples of presentation groups found under each heading, and for troubleshooting purposes if filers experience an unexpected result with this structure.

To take advantage of this navigation structure, presentation groups should appear in the following order:

• Document and entity information
• Financial statements and parenthetical disclosures
• Notes to the financial statements
• Significant accounting policies
• Table text blocks
• Detail tagged information

The following table shows the standard headings in the navigation structure and the presentation groups that appear under each of the standard headings. If the presentation groups are in a different order, groups may inadvertently appear under the Uncategorized heading. For example, if “Policy” appears after “Table”, all groups after “Policy” will appear under the Uncategorized heading. Note that using the plural form in a presentation group name, for example “Statements” or “Policies”, will not affect whether the group appears under its designated standard heading.

A: When applying dimensional modeling to the face financial statements, the XBRL viewer is programmed to render line items with an Axis (dimensions) after those without an Axis (dimension). Due to this rendering programming, it will not be possible to satisfy the requirements of EFM 6.6.7 through 6.6.10 and 6.13.3. Therefore, when using dimensions on the face financial statements, one should apply EFM 6.6.7 through 6.6.10 rather than EFM 6.13.3

A: Yes, to accommodate this scenario, merge the text from the three periods in a way that is readable and does not lose any information.

A: Yes. Please click on the following link to find the Mutual Fund Risk Return Summary Preparers Guide: http://xbrl.sec.gov/rr/2012/rr-preparers-guide-2012-03-26.pdf.

Also please click on the following link to access the Mutual Fund Risk Return Summary rendering guide, http://xbrl.sec.gov/rr/2010/rr-rendering-2010-02-28.pdf.

A: The schema files of a taxonomy that define elements, types or roles are listed on the SEC website (http://www.sec.gov/edgar/info/edgartaxonomies.shtml) as soon as the taxonomy is available for use in EDGAR.

Linkbase files of a taxonomy cannot generally be used except in specific circumstances, in which case the linkbase will appear in the list. Specific circumstances may include:

1. The linkbase defines a form, such as the Form N-1A, that mandates a particular presentation order, and the element labels need not be modified by the filer;
2. The linkbase contains definition relationships that cannot be overridden because they define a table of data structured in a way mandated by a Commission Rule.

Entry point schemas (schemas with no elements or types but only linkbase references) will generally not be allowed, except where they support exceptions (a) and (b) above.

A: US GAAP Taxonomy linkbases are 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 relationships. 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.

A: As EDGAR Filer Manual rule 6.6.29 says:

A: No. The rules in EDGAR Filer Manual chapter 6 apply to company extensions and instances. Although the standard taxonomies are consistent with many of the EDGAR Filer Manual rules, here are some exceptions:

• File names, namespaces, schemaLocation and xlink:href attributes of a standard taxonomy are not restricted by any of the EDGAR Filer Manual rules.
• Element declarations: A standard taxonomy might include elements that do not follow the LC3 convention.
• Role declarations: A linkbase xlink:role might be defined as being used on only one type of linkbase instead of all three.
• Linkbases: Since these linkbases will not be in the submission's DTS anyway, there may be any number of EDGAR Filer Manual violations.

A: The rule applies only to arcs in the company extension taxonomy. If the company extension taxonomy has a 'prohibiting' arc that prohibits an arc in a standard taxonomy, then it's the standard taxonomy that has the 'ineffectual' arc, not the company extension.

A: Filers should use the following values:

FY — Fiscal Year, used for annual filings

Q1 — First Quarter of the fiscal year, used for Form 10-Q filings

Q2 — Second Quarter of the fiscal year, used for Form 10-Q filings

Q3 — Third Quarter of the fiscal year, used for Form 10-Q filings

A: Yes.

A: You must provide one EntityCentralIndexKey element in the required context and it should be for the parent (consolidated) company. Note that required contexts are distinguished by having no xbrli:segment elements (e.g., dimension members).

A: The U.S. GAAP taxonomy is subject to accounting standards and changes. In general, we only support two versions of the U.S. GAAP taxonomy at one time. Indication that the updated taxonomy is available for use will be made via the standard taxonomies page at http://www.sec.gov/info/edgar/edgartaxonomies.shtml. The SEC staff strongly encourages filers to use the most recent version of the US GAAP taxonomy release for their Interactive Data submissions to take advantage of the most up to date tags related to new accounting standards and other improvements.

A: Use the XML numeric character codes from the column titled Character Reference (Dec) of the table in section 5.2.2.6.

A: EDGAR Filer Manual rule 6.11.1 states this more precisely. Roughly speaking, all the contents of the Original HTML/ASCII Document must appear somewhere in the EX-101 attachments, and all contents of the EX-101 attachments must appear somewhere in the Original. The rules adopted in Release 33-9002 do not require identical appearance, and neither does the EDGAR Filer Manual. Achieving adequate correspondence is the source of many of the "semantic" rules in EDGAR Filer Manual Chapter 6.

This is why standard label linkbases are usually not in the list of taxonomies on the SEC website. Consider: all element labels must match the exact wording in the Original HTML/ASCII file. If a standard label link base were included in the DTS of an instance, then any label that would be different would require both a prohibiting relationship as well as the new label. In the case of the XBRL US GAAP Taxonomies 1.0 us-gaap standard label linkbase, the file is 9MB, containing some 12,000 element labels, yet a very small percentage of those are ever likely to be an exact match to the line item of a filer's financial statement. The EDGAR Validator lets the filer assign a label to each element that is used in the instance, and requires no other labels. A filer should expect their company label linkbase to change in some way with every new filing, just as the instance will change.

A: EDGAR Filer Manual rule 6.7.12 explains that filers should develop an ordering and naming scheme that is appropriate to the organization of their Original HTML/ASCII Document while supporting a sensible (though obviously not identical) rendering. That implies filer-specific roles. Changing the roles frequently is akin to frequently changing the elements used in the instance: there is no rule against it, but given such freedom to define the roles at the outset, a reasonable amount of forethought should lead to a stable arrangement.

A: Please refer to the EDGAR Filer Manual section 6.5.21 for examples of the required context.

A: Yes. AmendmentDescription should be a nonempty fact if and only if the AmendmentFlag is set to true (EFM 6.5.20).

A: Yes. Starting with the 2009 US-GAAP taxonomy, a filer may use a language other than US English; Please see EFM 6.5.14 for conditions.

A: That restriction would not work because the domain-member relationship also represents the hierarchy of primary items.

A: Note that XBRL Dimensions 1.0 specification would require a validation error to be signaled if the targets were different, no matter in which link role they appeared. Furthermore, if the duplicated arcs had the same link role and priority one of them would be ineffectual and thus forbidden by rule 6.9.3.

A: XBRL 2.1 forbids duplicate role declarations in a schema file; 6.7.10 applies to the entire DTS.

A: Section 405(c)(1) of Regulation S-T (17 CFR §232.405(c)(1)) takes precedence.

A: A filer may simply not tag the element for line items appearing as an empty field or a dash. For example, if "Notes Receivable" appears on the balance sheet with a $1,000 balance this year-end and a dash last year-end, the filer can simply not tag the "Notes Receivable" element for last year's balance. Taking this action will render an empty field by our rendering engine for last year's balance. Our rendering engine will not currently render dashes. If the filer wants to tag one or more line items that appear with an empty field or a dash with a zero value because that's what management believes the item represents, and they think the distinction is useful, they can choose to do so. This guidance applies to all the financial statements, including the statement of shareholder's equity, the financial statement schedules, as well as to footnote data tagged at Level IV.

For the Commitments and Contingencies line item on the balance sheet where all columns are either blank or have dashes, the filer should set the NIL attribute to true without tagging the element with any information. This guidance is described under Edgar Filer Manual Section 6.6.15. Taking this action will render an empty field under all columns by our rendering engine.

Also, a filer may have a line item such as Preferred Stock on the balance sheet where all columns are either blank or have dashes. This could be the case when there are authorized shares, but none are issued. To tag monetary items such as this, the filer can set the NIL attribute to true without tagging any information, similar to the Commitments and Contingencies line item as described above. Taking this action will render an empty field under all columns by our rendering engine. Alternatively, the filer can tag the element with zeros if they believe the distinction is useful.

A: We strongly recommend that filers utilize the pre-defined table structures and axes as they exist in the US GAAP Taxonomies. Creating new hypercubes (tables) and dimensions (axes) should generally be avoided. Custom tables and axes have a negative impact on analysis of the financial information affecting comparability and should be avoided wherever possible. In addition, filers should also avoid creating new domains or changing default member elements for pre-defined dimensions.

For example, when filers are tagging a Property, Plant and Equipment note at Level 4, they should use the pre-defined dimensional Schedule of Property Plant and Equipment [Table], and axes; extending members or line items only when necessary. Similarly, filers tagging components of inventory presented with columns for each balance sheet period should use the pre-defined non-dimensional elements for that disclosure.

A: The Division of Corporation Finance's Compliance and Disclosure Interpretation for Exchange Act Forms 104.16 explains that, in cases of dual listed companies the filer may choose which CIK to use but should continue to use that CIK in every filing as long as the companies continue to be dual listed and file joint reports. Though not addressed in a CDI, in the consolidated parent company case, the CIK of the consolidated parent company must be used. In either of the aforementioned cases, that CIK must then be used uniformly throughout all the XBRL "identifier" elements in each filing, and the same CIK must be used in the identifier element consistently in every filing thereafter. This entity is referred to as the Consolidated Entity and is the "default legal entity," as described in EDGAR Filer Manual rule 6.6.3. When the facts about more than one entity are contained in a single instance document, it is known as a "consolidating instance" (see EDGAR Filer Manual rule 6.6.4). EDGAR Filer Manual rules 6.6.3 through 6.6.8 detail how to model a consolidating instance, and while they have been summarized in the table below, filers should consult the EDGAR Filer Manual for complete details.

EDGAR Filer Manual rules 6.6.3 through 6.6.8 contain examples and detail the technical structure of the dei:LegalEntityAxis, domain, and members. Additional information can also be found on the Public Seminar on Interactive Data Reporting Requirements Webcast, held Wednesday, June 10, 2009. Part 2 of the archived webcast, at approximately the 20 minute mark, provides additional detail about the multiple-registrant reporting scenario. Slide numbers 38-41 from the Panel 2 Slides (the slide deck which accompanies the webcast) specifically pertain to this portion of the webcast.

A: Currently, the CIKs of subsidiaries are not required to be reported within the single set of financial statements that satisfy the reporting obligations of reports such as Form 10-K. Because of that, the CIKs associated with the various subsidiaries are not required in the respective dei:EntityCentralIndexKey. The EDGAR system allows their inclusion but does not require them. For example, suppose the consolidated entity has a (hypothetical) CIK 9876543210. Then all of the "identifier" elements in the instance must contain 9876543210, and the value of dei:EntityCentralIndexKey in the Required Context must be 9876543210, and the value of dei:RegistrantName in the required context must be the name of the entity with CIK 9876543210. But suppose another (hypothetical) CIK, 8765432109, is reported in the same instance for subsidiary Abcd. In that case the filer may, but is not required to, include facts for dei:EntityCentralIndexKey and dei:RegistrantName that are in a context for which the dei:LegalEntityAxis has the member AbcdMember.

A: For an element with period type 'instant', if the disclosure includes the actual date, then use the date on which the event occurred. If the disclosure mentions that the event occurred in the month of May, then use the last day of the month, e.g. 5/31. If the disclosure only mentions that it occurred in the second quarter, then use the second quarter reporting end date of 6/30. For an element with period type 'duration', if the disclosure mentions that the event occurred in the month of May, then use the duration period 5/1 to 5/31. If the disclosure only mentions that it occurred in the second quarter, then use the second quarter period of 4/1 to 6/30.

A: EFM 6.8.6 applies to elements with item types other than 'domainItemType'. Elements with other item types, including (but not limited to) monetary, percent, integer, shares, per share, string, or text block item types, should not include company-specific or period-specific information in the element name. Domain members may include company-specific or period-specific information in the element name.

For example, filers should not create a monetary element with the name "AcquisitionOfDefCo" or "FourthQuarterAdjustment". However, they may create a domain member with the name "AbcSegmentMember".

A: Every amount in an XBRL submission is associated with an XBRL item type, an underlying data type, and a unit (short for "unit of measure"), determined by the element selected and the nature of the amount being reported. Common XBRL item types include Monetary, Shares, Decimal, Integer and Pure. These may be further distinguished as to data type, which could be the same as the item type or a specialization of it; for example, the Monetary data type allows any number to appear; the Non Negative Monetary data type excludes negative amounts. The US GAAP taxonomy and SEC taxonomies mainly use data types defined in XBRL 2.1 itself or in the standard Data Type Registry (DTR).

The XBRL item type and data type are still not enough in most cases to completely define an amount, and so XBRL 2.1 requires every amount to have a unit. In this way, XBRL item types, particularly Decimal or Integer item types, use units to further distinguish the nature of the amount. For example, the unit used for earnings per share amounts reported in US dollars is "USD per Share". Specialized units also are used to report nonmonetary measurements. For example, amounts may be reported in units of measure such as megawatts, millions of barrels, millions of bushels, or employees.

The Pure XBRL item type is used with elements that describe percentages, rates, and ratios, and typically use the Pure unit. However, the staff has observed some filings to date in which the Pure unit has been used for other item types. The staff recommends as a best practice and to promote consistency and comparability that the Pure unit only be used with the Pure XBRL item type, and not with other item types. Additionally, the staff recommends that the Pure unit be used only for amounts which are percentages, rates or ratios.

Under EFM 6.5.35, if a standard numeric data type registry namespace is in the DTS of an instance, then the unit used for an item type must be the unit listed in the registry for that item type. Currently, the standard units registry is not yet available. The Staff expects that it eventually will be included in a future version of the DEI (Document and Entity Information) Taxonomy and notice will be provided of its inclusion. Until it becomes available, the staff recommends as a best practice that filers select the unit type that most closely fits with the item and data type. The following table gives examples of commonly used XBRL item types, data types and corresponding units:

A: It depends on the type. Only one EX-101.INS (instance) is required and allowed. However, as EFM 6.3.10 implies, the submission must contain at least one EX-101.SCH (schema) but may contain more. In general there can be any number of EX-101.PRE (presentation linkbase), EX-101.LAB (label linkbase), or EX-101.DEF (definition linkbase) attachments (EFM 6.8.2). The total number of attachments is subject to any overall limit on attachments imposed by EDGARLink Online.

Additionally, EFM 6.7.4 and 6.7.5 together allow the targetnamespace attribute of each schema to have formats such as "http://example.com/20111231", "http://x.example.com/20111231", "http://y.example.com/20111231" and so forth.

A: Yes. Unused elements (i.e., those elements which do not appear in the current instance document exhibit) and their linkbase relationships may be contained in the extension schema to simplify maintenance and reuse (e.g., between quarterly and annual reports) of the extension schema. However, it is recommended that unused elements and relationships that serve no further purpose be removed from the extension schema.

A: Yes, calculations that meet the EDGAR Filer Manual rules for calculation linkbases (see EDGAR Filer Manual rules in sections 6.14 and 6.15) outside of a required context are optional. Note that required contexts are distinguished by having no xbrli:segment elements (axes and dimension members).

A: Every required calculation relationship applies to the entire filing. An element should be the source (e.g., current liabilities) of only one calculation relationship for any one target (e.g., current portion of long-term debt), without regard for base set (e.g., balance sheet, debt footnote). See EDGAR Filer Manual section 6.15 for additional detail.

A: EDGAR Filer Manual rule 6.3.3 indicates that document names should begin with the registrant’s ticker symbol or some other mnemonic abbreviation and should be the same as that used for the instance in the same submission. Although not a requirement, if a company subsequently changes names or ticker symbols, we suggest the file names and recommended namespace prefix mnemonic abbreviation be updated to reflect the change.

A: The Commission's rules require filers to include calculation relationships for certain contributing line item elements for financial statements and related footnotes. Required calculation relationships in XBRL company taxonomies provide key information that shows the relationships among elements and their corresponding numeric facts, and how they add and subtract to each other. In addition, required calculation relationships enhance data quality by:

• Providing vital context for interpretation of custom element extensions;
• Supporting company data continuity; and
• Reducing the number of incorrect amounts.

The EDGAR Filer Manual (Volume 2), Chapter 6, Sections 6.14 and 6.15 set out specific calculation relationship requirements, including certain examples and exceptions. Section 6.14 addresses the syntax restrictions of calculation relationships. Section 6.15 addresses the content of calculation relationships.

Item 6.15.2 of the EDGAR Filer Manual states:

If a line item satisfies all of the following five conditions, as set out by Item 6.15.2, the line item requires a calculation relationship:

A: No. There is no requirement that facts tagged at Level 4 render in such a way to match the formatting in the original HTML/ASCII version. For example, the axes may be reversed in the XBRL table structure from that presented in the original HTML/ASCII version and there may be blank cells in the XBRL table structure where "-" appear in the HTML/ASCII version. In addition, facts appearing within the same footnote in the original HTML/ASCII version may be incorporated into the table structure for tagging purposes.

A: Yes, but see the clarification in Question E.20.

A: Yes, including the superscripted text at the bottom of a footnote table in an XBRL footnote link is optional. Note that any required amounts in superscripted text must be separately tagged as part of Level 4 tagging requirements.

A: In general, if you can replace the word "no" or "none" with a zero and it does not change the meaning of the sentence, then you are disclosing an amount. From Compliance and Disclosure Interpretations - Regulation S-T Question 130.04 — "Each amount, whether expressed numerically or textually, must be tagged separately under Rule 405(d)(4)(i). This guidance also applies to tagging each amount within the financial statement schedules under Rule 405(e)(2)(i) of Regulation S-T. Each tagged amount must be mapped to the applicable monetary, decimal, percent, integer or shares data type element".