Issues Raised in DFAS XBRL Proof of Concept

[Cache from http://xml.gov/dfas_xbrl_issues.htm; please use this canonical URL/source if possible.]

Issues Raised in DFAS XBRL Proof of Concept Department of Defense (DoD) XML Environment: XML is the 21^st Century industry data/metadata interchange format of choice, vital to the DoD’s interoperability strategy.

Under the guidance of the Defense Information Systems Agency, the Defense Information Infrastructure Common Operating Environment (DII COE) Chief Engineer has established a XML management framework and web based registry for DoD XML users. This framework is designed to address the causes of non-interoperable XML and ballooning management overhead resulting from proliferation of XML groups. One mechanism for addressing data disambiguation (collisions/conflicts) is the namespace concept. Within the DoD XML namespace and registry, the Defense Finance and Accounting Service (DFAS) is the manager for DoD finance and accounting data items (tags).

In carrying out this responsibility, DFAS is developing a technology adoption strategy for the XML family of technology. Using this approach, DFAS identifies a technology "area of opportunity " and proactive sponsor. Our first area of opportunity identified was financial reporting and the DFAS sponsor was Accounting Directorate. The Agency selected this area as a "proof of concept" because the eXtensible Business Reporting Language (XBRL) is a market based framework that provides a method to prepare, publish, extract and exchange commercial financial statements, and that a Federal taxonomy was under development for Department/Agency reporting.

Proof of Concept: KPMG Consulting, LLC was contracted by DFAS to provide an XBRL proof of concept. XML and XBRL are emerging technologies, and a proof of concept was necessary to assess the applicability of XBRL in meeting DFAS strategy. The proof of concept was designed to demonstrate the ability to dynamically create DoD financial statements in HTML through the use of XML technology and more specifically XBRL. The HTML was selected as the final output based on its ability to be viewed by a large audience through the use or a browser.

In order to demonstrate this, KPMG started with the XBRL (in process) Federal Taxonomy, which restates the OMB Form and Content for Federal financial statements. This taxonomy was extended for differences in the DoD Form and Content. Next, actual balance sheet data was populated in the XML document to create an XBRL instance document. XSLT style sheets were then created to dynamically generate three HTML documents representing a consolidated and consolidating balance sheet as well as one footnote . Additionally, links were inserted in the balance sheets to demonstrate the capability to "drill down" into detailed data from a summary presentation.

In Summary, the DFAS XBRL proof of concept project demonstrated the ability to render financial data in HTML through the use of XBRL. By using XBRL, source data modifications resulted in dynamic updates to the HTML documents. In addition, the HTML documents contained links that could transport a user to detailed subsidiary data (if available). However, our XML technical adviser, the Mitre Corporation, raised some very important discussion points that we wish to share, with our contemporaries, in the Federal XML domain. The technical evaluation paper is enclosure 1.

Topics Proposed by DFAS for Consideration by Federal CIO Council XML WorkingGroup: In keeping with activities of the XML.gov working group, we wish to present 3 topics for discussion in the Federal domain. Details relating to these 3 topics are found in the paragraph and annex references found in the discussion point paper (enclosure 1).

Generic XML validating parser versus tailored XML validation parser adoption strategy. Reference enclosure 1: paragraphs #4, 6, 7, 9, and Annex 2.
Degree of deviation acceptable from W3C concepts related to Schema/Taxonomy? Reference enclosure 1: paragraphs # 5, 6, 8, & 9.
Use of generic (wrapper-like: group & item) versus specific (domain specific: assets, liabilities, equity) XML tags. Reference enclosure 1: paragraphs 4, 5, 9, Annex 1, Annex 2.

Enclosure 1, paragraphs 1 & 2 - points are informational in nature and were not framed to foster CIO discussion.

Enclosure 1, paragraph 3 - is intended to document how an XBRL tag would be represented in the DoD Namespace registry.

Enclosure 1, paragraph 10 - comments are specification clarification points and were not framed to foster CIO discussion.

The XBRL "Proof of Concept" and related documents were prepared under the direction of the DFAS Data Management Division. Inquiries should be addressed to Mike Lubash, DFAS-DTD, telephone: 703.607.1166 or email: mike.lubash@dfas.mil.

Enclosure 1 - Discussion Points Pertaining to Extensible Business Reporting Language (XBRL)

Requested by the Defense Finance and Accounting Services (DFAS) to document and communicate technical findings related to the "DFAS proof of concept" using XBRL.

Issues collected and drafted by Christopher J. "Kit" Lueder, The MITRE Corporation, 7 December 2000.

Note: The following is a work in progress, not a completed document, and consensus has not yet been reached on these issues.

Terminology:

XBRL: Extensible Business Reporting Language (XBRL), an industry consortium specification for a data format for financial reporting.

XBRL Instance Document: An actual financial report document to be exchanged in the financial community.

XBRL Specification: The XBRL Specification provides the definitions for the syntax and use of XBRL instance documents and XBRL taxonomy documents. The specification and instance examples may be downloaded from their website (http://www.xbrl.org/).

XBRL Taxonomy: A file that defines the data reporting fields (e.g., "liabilities", "fundBalanceWithTreasury", "cashAndOtherMonetaryAssets", "accountsReceivable", "loansReceivable", "inventoryAndRelatedProperty"), and their relationship to each other (e.g., that "accountsReceivable" is part of "assets").

XML: Extensible Markup Language, a standard of the World Wide Web Consortium (W3C, at http://www.w3c.org/), for structuring data in a flexible machine-processable manner.

XML Schema: The standard way for defining the structure and business rules for XML documents (or the older specification Data Type Declaration (DTD)).

Information Points

1. XBRL is the product of a vendor consortium, developed by a committee made up of companies representing the financial information supply chain, coordinated by the American Institute of Certified Public Accountants (AICPA). MITRE has heard speculations that XBRL might spin off from the AICPA, but the XBRL website does not have a definitive statement on the future organization. The XBRL website does not give any indication of efforts to pursue standardization of XBRL under a standards body such as the World Wide Web Consortium (W3C), American National Standards Institute (ANSI), or International Organization for Standardization (ISO). The XBRL website and the documents

http://www.xbrl.org
http://www.xfrml.org/legal/copyright-documents-2000-03-31.html
http://www.xfrml.org/legal/copyright-software-2000-03-31.html

state that XBRL must be licensed from AICPA for its use, although apparently at no cost. "The software, Document Type Definitions (DTDs) or schemas associated with XBRL specifications are governed by the Software Notice" ... "XBRL.ORG is not a formally incorporated organization, instead it is a contractual entity arising from agreements between the host institution [AICPA] and our members."

2. The XBRL can be a useful exchange format for reporting financial information in a common XML-based document, if all parties implement and support the XBRL-specific technology. While no insurmountable technical reasons have been identified that would prevent the use of XBRL for financial reporting, the question is whether XBRL is the best or most cost effective method, or whether the XBRL specification should be modified or enhanced to meet better the financial communities needs. This point paper does not include analysis of the XBRL design discussed in the paper "Design of the XBRL specification"; see Annex 4 for a summary of that topic.

Discussion Points

3. The XBRL specification does not make use of the Department of Defense (DoD) Namespace Registry, aside from trivial use for the two high-level XBRL XML tags "group" and "item". The financial data reporting fields of interest to the Government ("assets", "liabilities", etc.) are used as data value strings in the XBRL instance document. A mechanism or procedure separate from the Namespace Registry is needed to ensure consistency and shared use of these XBRL data fields.

For background information, the Common Operating Environment (COE) XML Namespace Managers' Forum and SHADE are developing Namespace Registry databases for the DoD to ensure consistent use of XML element tags and to avoid conflicting definitions for the same data. One namespace area is "Finance and Accounting", managed by DFAS. (See Annex 1, below, for examples of how XBRL taxonomy fields are represented as text data strings, appearing to the right of the equals-sign for attribute "type", not as XML element tags that can be registered in the Namespace Registry.)

4. A generic XML validating parser would not validate an XBRL instance document against an XBRL taxonomy, since the elements defined in the XBRL taxonomy appear as data values (alpha-numeric strings, given as values of the XBRL "type" attribute) in the XBRL instance document, not as XML element or attribute tags. It requires XBRL-specific programming logic to validate an XBRL instance document against the XBRL taxonomy document, and to process and use the information appropriately.

For background information, XBRL uses an XBRL-specific syntax for defining a taxonomy, which shows the structure of the business reporting data, such as in the following small excerpted example:

<element name="balanceSheet.assets" type="monetary">
<annotation>
<appinfo>
<xbrl:rollup to="statements.balanceSheet" weight="1" order="1" />
<xbrl:label xml:lang="en">1. Assets</xbrl:label>
</appinfo>
</annotation>
</element>

Note that while this XBRL taxonomy syntax is based on the standard W3C XML Schema specification, XBRL-specific extensions are defined:

- "rollup", "label", "reference" elements
- "monetary", "shares" data types
- two-part taxonomy field names delimited by a period.
- the taxonomy field names are defined as XML element names, but are used as attribute data values, not as XML elements.

Validation of an XBRL instance document requires special XBRL-aware parsers, since the XBRL specification imposes specific implementation requirements beyond those of general XML. Implementation can be complicated by the special requirements of that specification, such as: -- to support and process the taxonomy document and references to the taxonomy in the instance document.

-- to support the special date format, which combines several different pieces of information into one field (e.g., the duration of a period [one month, three months, one year, etc.] and the stop date of the period).

-- to parse many attributes in the instance document, and process data where the only XML element tags are "group" and "item".

5. The standard way for defining the structure and business rules for XML documents is using XML Schema (or the older specification Data Type Declaration (DTD)). However, XBRL does not benefit from this capability, since it developed its own mechanism (XBRL taxonomy) for defining its schema. While it is true that XML Schemas cannot convey all the business rules one needs to fully process an XML input, is it appropriate to ignore any opportunity to convey as many of the business rules in the schema as possible?

The XML Schema is intended to be used to define XML elements and attributes. XBRL instead uses the XBRL taxonomy (which is based on XML Schema) to define attribute data values in the XBRL instance document.

The XBRL approach uses XML only to the extent that an XML parser can load the XML of the XBRL instance document into a (very flat) tree, consisting of "item" elements nested within "group" elements. To further process the XBRL instance document, a separate process is required. In essence, XBRL is using XML to package data text fields that contain attribute/value pairs (where the attribute is the financial report line item type and the value is the numeric value to be reported).

The paper "Design of the XBRL specification" states:

"Ideally, the namespace declarations, which are referenced by the prefix parts of the Qualified Names of the type attribute content, would be sufficient to connect that content to the schema document. Unfortunately, that does not seem possible to enforce." Note that this unmet XBRL requirement is achievable with minor adjustments to the XBRL specification, where the XML Schema is used to define specific element tags, not values of the "type" attribute. XBRL uses DTDs for the definition of the "group" and "item" elements, and their associated attributes. The specification should now be updated to be based on XML Schema for the definition of these core elements and attributes.

6. The availability of production-quality XBRL-specific software is to be determined, both for the generation of XBRL instance documents (financial reports) and for the processing and use of the received data. While a generic XML parser can parse an XBRL document, the parser would not associate the XBRL instance document with the taxonomy file, and would not validate the structure of the XBRL instance document and the item type references against the XBRL taxonomy file. Therefore, XBRL-specific software is required for the generation or receipt of XBRL instance documents. One vendor of software for XBRL-specific data structures is XBRL Solutions (http://www.xbrlsolutions.com/), including XBRL Instance Document Validator and XBRL Custom Taxonomy Builder software.

7. The XBRL approach does not allow for including sub-totals or totals in the financial report statements. When processing the reports the application must know how to add or subtract all the elements appropriately (e.g., that liabilities are subtracted from assets, even though both are expressed as positive numbers), in order to determine the totals. When processing financial reports, the totals must be computed, rather than extracting the totals from the documents; this means that a simple XML parser cannot be used, but that an XBRL application must be used to process the financial reports. Note that XBRL's design goal was to support the transmission of facts tied to a financial taxonomy, not totals and sub-totals, but that design decision prevents the use of generic XML parsers to process XBRL instance documents. (See Annex 2 for a further example of this.)

8. The XBRL date period specification appears to be consistent with the International Organization for Standardization (ISO) standard 8601:1988 specification (http://www.iso.ch/markete/8601.pdf). The XBRL specification should clarify that the date must use a four-digit year format, since that ISO specification does allow short-hand formats.

Individual dates in XBRL (as opposed to a date period) appear to be consistent with the W3C specification for date and time (http://www.w3.org/TR/NOTE-datetime). However, the XBRL date period specification is inconsistent with the W3C XML Schema "timeDuration" specification (http://www.w3.org/TR/xmlschema-2#timeDuration) . The XML Schema approach (where a date period is a kind of time period) is as follows:

"Time periods, i.e. specific durations of time, can be represented by supplying two items of information: a start instant and a duration or a start instant and an end instant or an end instant and a duration."

Instead, XBRL chooses to pack both the duration and the stop date into a single field. The XBRL approach of combining more than one piece of data into one field is generally inadvisable because (a) it is a poor programming practice to have one data field convey more than one piece of information, and (b) special XBRL-specific parsing software or applications may have to be programmed, since Commercial Off The Shelf (COTS) XML parsing tools are more likely to support the format specified in XML Schema. For example, in XBRL a date value of "P1Y/2000-09-30" is used to indicate: - The period is one year (P1Y) (or it could be P3M for a three-month period)

- The year is 2000, with the period ending on September 30.

9. Processing of XBRL instance documents may be more heavily computer processing intensive (resulting in slower performance), since XBRL makes heavy use of XML attributes that contain user data. This is a different direction from the approach of many other XML schemas. In XBRL all the data is provided as an attribute to the XML "group" and "item" elements, or as the value of an "item" element. This means that searches (whether an XML search, Extensible Stylesheet Language (XSL) transformation, or a database search) must be performed on the values of the elements and attributes, not on the element and attribute tag names (unless the instance document is parsed by an XBRL parser and stored differently). A query to an XML document (or an XML-enabled database), for example, for an element of "item" would match on and return all item fields, whether they were relevant to the desired search results or not. The XBRL XML syntax is a flat structure of unordered elements, and the XML structure does not show the nesting of data (e.g., that assets are composed of the line items containing cashAndOtherMonetaryAssets, accountsReceivable, loansReceivable, inventoryAndRelatedProperty, otherAssets, etc.). Taken to the extreme, the user may even intermix data from different forms in one submission. Also, since all financial data in an XBRL instance document is an item and its attributes provide the metadata (i.e., the context for the use/meaning of the data value), this subverts any ability to encode any business rules into a DTD or XML schema. XBRL taxonomies use the rollup element to support one form of higher order business rule (to indicate the nesting of data fields and whether they are additive or subtractive), but that requires the parser or user application to process the XBRL taxonomy file and associate that information with the "type" attribute values in the XBRL instance document.

Specification Clarification Points

10. There are many examples indicative of further development work and clarification required in the text of the XBRL Specification document (Version 2000-07-31). The remaining issues/discussion points below pertain to this topic category.

10.1. XBRL Specification Document, Section 5.3 "The Parent-Child Relationship" states: "There is no nesting of XBRL items. Whatever structural relationships as might be desirable in an XBRL instance document are captured in rollups." (This states that the way to show relationships between "item" elements in XBRL is by using the "rollup" element of the XBRL Taxonomy.)

Furthermore, the definition of "group" element (page 5) states:

"Text containing a collection of items that concern one or more entities during one or more time periods." (This also implies that a "group" element can have an attribute of "entity" or "period", but not "type".)

However, this seems inconsistent with the definition of "tuples" and the examples and text in Section 3.13 "The group element", which shows the use of a group with an attribute of "type".

10.2. Informative (i.e., not "normative") examples are used to show the formation of date periods. The document provides inconsistent examples. For example, in some places the "period" date attribute has hyphens between the year/month/day fields, but not in others.

10.3. The document has imprecise specification of normative requirements, in terms of what is the essential compliant behavior ("should", "must"). The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" be used as described in Request for Comments (RFC) 2119: http://www.normos.org/ietf/rfc/rfc2119.txt

10.4. Section 3.13, "The group element". The concept of "tuples" (related elements, such as in a table row) is poorly defined. This section is vague in distinguishing between which grouped items form related tuples, and which items are grouped just because they have common attributes. The last paragraph of 3.13 relies on the last example of 3.13 to depict the use of group to create tuples of data, but that is ineffective since examples are informative, not normative. The text is round-about and inadequate:

"If the group element contains an attribute, and an item within that group contains the same attribute with a different value, then the group cannot be removed without loss of information. This situation can occur when groups are used to create the equivalent of table rows or tuples." Specific wording should be added to that paragraph to state in a normative manner in which cases a group of items forms a tuple and in which cases it does not.

Regardless of how Section 3.13 is worded, this syntax is less than ideal, putting an unreasonable burden on the parsers and allowing for the accidental definition of a tuple when specifying a group of items of different type. A better approach instead is to add an attribute to the group such as: tuple="yes"; this is unambiguous and much easier to parse then having to analyze the specific combination of presence and value of type attributes.
10.5. Section 2, "XBRL Framework", "Tuples" definition. The tuples could be defined in a more precise manner. For example, it describes tuples in terms of facts (which are items that have associated groups) rather than in terms of items (without each item having its own group).

Annex 1: Examples of the common XML encoding approach versus XBRL encoding.

One aspect of XBRL (www.xfrml.org) is its wrapper-like use of XML, rather than the common XML encoding approach of defining a set of domain-specific tags. An example of a common XML encoding approach is as follows:

<fc:FinancialReport period="P1Y/2001-09-30" entity="DOD:AirForce" xmlns:fc="http://www.dod.gov/DFAS/2000/us-dfas-fed-2000-09-11A">
<fc:liabilities>
<fc:otherLiabilities>45005499.67</fc:otherLiabilities >
</fc:liabilities>
<fc:assets>
<fc:cashAndOtherMonetaryAssets>0.00</fc:cashAndOtherMonetaryAssets >
<fc:accountsReceivable>2811558.67</fc:accountsReceivable >
<fc:loansReceivable>0.00</fc:loansReceivable >

<fc:inventoryAndRelatedProperty>0.00</fc:inventoryAndRelatedProperty >
<fc:otherAssets>1805025.61</fc:otherAssets >
</fc:assets>
<fc:TotalAssets>1000000</fc:TotalAssets>
<fc:TotalLiabilities>.99</fc:TotalLiabilities>
</fc:FinancialReport>

In this example, the XML elements <FinancialReport>, <TotalAssets>, and <TotalLiabilities> can be defined in an XML Schema specification, which can be processed by a COTS XML validating parser. Thus, the syntax and business rules of the XML document can easily be validated and enforced.

In contrast, XBRL has created just two generic element tags ("group" and "item" only) and some generic attribute tags ("type", "period", "entity", and a few others). XBRL uses an attribute's value (in the attribute "type") to carry the metadata term (which provides the meaning of the data value), for the identification of the line item in the financial report. (See Annex 3 for a more complete example of an XBRL instance document.)

</group>

The metadata terms (e.g., "assets.loansReceivable") are described in an XBRL taxonomy document (with the "fc:" prefix identifying which taxonomy file is to be used, in this example), but that taxonomy is not used for XML element tag names, and the names would not appear in the Namespace Registry. All that would be registered there are the element tag names "group" and "item", and maybe the attribute tag names such as "type", and "period".

Annex 2: Clarification on XML parser inability to process XBRL documents effectively

First, here is an overview of an XBRL instance document (financial statement). Refer to the XBRL instance document example given in Annex 3, below. In this instance, one "group" element is the root tag, which defines the common attributes for the entire instance document. Another "group" element describes one column of the financial report table; in this case it is for entity="DOD:AirForceActive". Then there are a series of "item" elements, which can be provided in random order, providing the information for each line-item of the financial report, with the value of the attribute "type" identifying the type of the line item (e.g., "fc:assets.inventoryAndRelatedProperty").

A generic XML parser (i.e., one that is not familiar with XBRL syntax specifically) cannot validate the XBRL items against the XBRL taxonomy, cannot determine the relationship between the items, and cannot process the financial information properly. Special XBRL-specific software must process the externally-defined schema taxonomy file, which is given in "schemaLocation" attribute. The generic XML parser cannot assist the user's application in determining that the following are line items pertaining to assets, which should be added together:

- "fc:intragovernmental.fundBalanceWithTreasury"

- "fc:intragovernmental.investments"

- "fc:intragovernmental.accountsReceivable"

- "fc:intragovernmental.otherAssets"

- "fc:assets.cashAndOtherMonetaryAssets"

- "fc:assets.accountsReceivable"

- "fc:assets.loansReceivable"

- "fc:assets.inventoryAndRelatedProperty"

- "fc:assets.generalPropertyPlantAndEquipment"

- "fc:assets.otherAssets" Similarly, the generic XML parser cannot assist the user's application in determining that the following are line items pertaining to liabilities, which should be added together: - "fc:intragovernmental.accountsPayable"

- "fc:intragovernmental.debt"

- "fc:intragovernmental.environmentalLiabilities"

- "fc:intragovernmental.otherLiabilities"

- "fc:liabilities.accountsPayable"

- "fc:liabilities.militaryRetirementBenefitsOtherEmploymentLiabilities"

- "fc:liabilities.environmentalLiabilities"

- "fc:liabilities.loanGuaranteeLiability"

- "fc:liabilities.otherLiabilities"

In a normal XML environment (i.e., not XBRL), there would be something like a tag of "assets" and all the assets line items would be grouped between that <assets> and </assets> pair. And there would be something like a tag of "liabilities", and all the liabilities line items would be grouped between that <liabilities> and </liabilities> pair. The XML element hierarchy nesting would directly indicate these association explicitly, so the XML parser wouldn't have to go to an external taxonomy schema to determine what data went where.

Also, if the XML document contained the totals, the recipient's application software (which invoked the XML parser) would not need application-level logic about which elements were additive and which are subtracted. (In this case, the liabilities are subtracted from the assets, but there could be more complicated examples, such as of adjustments given within one of those sections.)

Therefore, a generic XML parser cannot be used to process an XBRL document effectively.

In situations such as document submissions to the IRS, the customer is required to submit both totals and detail amounts. Part of the validation process is the comparison of the reported totals with the computed totals. The absence of reported totals means that an opportunity for error checking is lost.

Annex 3: An example of an XBRL Instance Document

<group period="P1Y/2000-09-30"

scaleFactor="0" precision="18"

unit="ISO4217:USD" entity="DOD:AirForce"

type="fc:statements"

xmlns:fc="http://www.dod.gov/DFAS/2000/us-dfas-fed-2000-09-11A"

xmlns:DOD="http://www.dod.us.gov/2000/orgchart"

schemaLocation="http://www.dod.us.gov/2000/orgchart

http://www.dod.us.gov/2000/orgchart.xsd

http://www.dod.gov/DFAS/2000/us-dfas-fed-2000-09-11A

http://www.dod.gov/DFAS/2000/us-dfas-fed-2000-09-11A.xsd">

</group>

Annex 4: Paper "Design of the XBRL specification"

MITRE reviewed the paper "Design of the XBRL specification", written by David Vun Kannon and Yufei Wang of KPMG Consulting, LLC. It may be obtained from URL: http://www.gca.org/papers/xmleurope2000/papers/s26-01.html

MITRE determined that much of the paper is not relevant to the XBRL review, because:

- It is an informal paper authored by two individuals.

- It does not seem to be an XBRL-endorsed paper, and was not obtained from the XBRL website.

- It is inconsistent with the current draft of the XBRL specification in some ways (e.g., the description of valid values for a date/time period, lack of discussion of "tuples"), since it seems to be tied to an out-of-date version of the specification (2000-03-31).

- It focuses on rationale for the design decisions, while this review focuses on the XBRL syntax and compliance requirements.

- The paper references XML for General Financial Reporting (X4GFR), which seems to be an obsolete term.

Some information was derived from the design paper, however, such as the identification of an unmet requirement to use the XML Namespace standard to validate the XBRL elements against the XBRL taxonomy; see paragraph 5 in the above list of discussion points for a way to meet that requirement.