Blank document

COMMENT #1

From: Kit Leuder

Subject: XBRL Draft Review Comments

Date: 05/17/00 12:00pm

“MITRE did a draft review of document "Extensible Business Reporting

Language (XBRL) Version 0.9 Specification, 4 April 2000 (with

corrections 6 April 2000)"

Concerns with XBRL (many of which are fundamental design decisions in

the development of XBRL) include:

1) XBRL doesn't seem to flexibly accommodate the context information for

the financial data being reported, such as the company name and address

for which the data is being reported. The examples in the XBRL

specification show either the financial XML data being embedded in an

HTML web page (where the web page text shows the context), or the

company organization being hard-coded in the XBRL taxonomy (which is not

a general purpose solution, since every organization would need to

create its own taxonomy, and it would change as the usage/reporting

approach changes or the organization structure changes). This also

doesn't work if you have a fluid organizational structure.

2) XBRL doesn't seem to accommodate table-oriented data, where the data

components being reported cannot be predetermined. For example, it

doesn't support reporting the list of interest income sources on a 1040

Schedule B (where you specify the bank/investment method and you specify

the interest income amount, but XBRL doesn't provide a way to associate

the two together). Other examples of where XBRL wouldn't work would be

for Fidelity reporting the yield on all of its mutual funds or itemizing

the stock portfolio invested in (stock names and number of stocks held)

by a particular mutual fund, or NASDAQ reporting the closing stock price

of all NASDAQ stocks. The problem is that you can list all the NASDAQ

stocks, and you can list the stocks' closing prices, but you can't say

which closing price item is associated with which stock name item. You

can't define a taxonomy that elaborates all NASDAQ stocks, because it is

obsolete as soon as it is published, given the dynamic nature of the

thousands of NASDAQ stocks. If these comments are accurate, XBRL may not

be applicable to other vertical domains outside the financial sector,

and probably doesn't meet the needs of the financial sector either.

3) The XBRL XML syntax is a flat structure of unordered elements, and in

the XML does not show the nesting of data (e.g., in an IRS 1040 Tax

Return, that AdjustedGrossIncome is Income and Deductions, and Income is

Wages & Interest & Dividends & Alimony, etc.). Taken to the extreme, the

user may even intermix data from different forms in one submission.

4) It uses non-standard date/time definitions, which requires parsing of

a text string into sub-string date and time fields. Combining more than

one piece of data into one field is usually a no-no because (1) it is a

poor programming practice to have one data field convey more than one

piece of information, and (2) special parsing software needs to be

programmed because COTS tools won't support special encoding formats

like this one.

5) XBRL makes heavy use of XML attributes that contain user data; this

is a different direction from the approach of many other XML schemas.

6) The taxonomy approach used in XBRL is not supported yet by XML

software tools, in terms of validating the XBRL document against the

taxonomy structure.

7) It uses non-standard abbreviations, such as a short-hand notation for

the Xpointer standard method of cross-reference.

8) Other notes of typographical/grammatical errors in the XBRL document:

Section 3.2, next to last paragraph. "Since any date by itself is can be

interpreted..."

Drop either the "is" or the "can be".

Section 3.5, first paragraph. "The schemaLocation attribute is used to

hold the base URI of the taxonomy which includes the concept of which

the item is an instance."

If the part after "taxonomy" is a subordinate clause, put a comma before

the first "which"; otherwise change the "which" to "that".

Drop "the" after the second "which".

Section 3.12, second paragraph. Change "IDRDF" to "IDREF".

Section 3.14, first paragraph. change "is th" to "is the".

Section 3.16, second paragraph. In phrase "which may appear either

attached to an element of higher up in the document tree", either drop

the "either" or change "of" to "or".

Section 3.17.2, second paragraph. "The use of a general group construct

to assign content to those attributes, mean that pure XBRL documents

resemble a database more than they resemble a presentation-oriented

document."

Drop the comma before "mean", and change "mean" to "means".

Section 4.1, first paragraph. "Monetary strings are interpreted with

respect the enclosing decimalFormat for any item where they appear."

Add "to" after "respect".

Section 4.1, first paragraph. "A taxonomy which includes numeric

elements that are meant to be interpreted as monetary values should use

this datatype rather than "string", which is the default."

Change the first "which" to "that", since it is not a subordinate

clause. If "which" is kept, put a comma in front of it. (Also for several

other occurrences of "which" in the document.)

Section 5.2, second paragraph. Change "shemaLocation" to

"schemaLocation".

Section 5.3, last paragraph. "...suggests that it has poor modularity is

poor, but..."

Drop one of the two instances of "poor".

Section 5.4, last paragraph. "XBRL allows for producing applications to

create documents which that are either complete or incomplete,..."

Change "which that" to "that".

Explanatory note to the "cc" recipients:

This was in response to a question of what XML-related work is being

done at American Institute of Certified Public Accountants (AICPA): They

are sponsoring an effort Extensible Business Reporting Language (XBRL),

formerly XFRML. According to their website, "XBRL is an open

specification that uses XML-based data tags to describe financial

statements for both public and private companies. XBRL benefits all

members of the financial information supply chain." Currently, XBRL is

in a "request for comment" phase.

XBRL is described at:

http://www.xfrml.org/

and an overview of it is given at:

http://www.xfrml.org/Overview.htm

XBRL is a generic mechanism, where you don't need to define distinct XML

elements for each field in the tax form, though you do need to define

each field in the associated taxonomy specification.”

RESPONSE #1 to COMMENT #1

From: David Vun Kannon

Date: 05/18/00 5:15pm

1) This is probably the first time XBRL has been faulted for not being flexible

enough, as opposed to being too flexible! Part of XBRL is the idea of the organizational entity for which a particular financial fact is true. The entity attribute is the way to specify this. As designed, entity is a key into some other space, and in that space we can find out the context, as Kit puts it. So entity="DUNS:1234567890" says 1234567890 is a key in the Dun and Bradstreet namespace sufficient for the task of providing context. That is fine, if you have access to that namespace. Then you can use the key and resolve the reference to the entity. It is also possible to represent an organizational structure explicitly using XBRL's taxonomy constructs. This creates a namespace which can be used within the entity attribute. We don't assume companies will do this or need to, it is just one of the 'neat' uses of XBRL taxonomy. To Kit's concern about this being a 'hard-coding' of the company's org chart in an XML document, my response is that the org chart is already hard-coded somewhere (the G/L, the ERP system, a spreadsheet) and an XBRL taxonomy is just a serialization syntax for that content. There is no expectation by the designers of XBRL that companies will stop using ERP systems built on relational databases in favor of a pile of XML documents. However, if I have to communicate my org chart, either in its own right or as part of the process of communicating selected financial or business information, XBRL does provide a way to do that. Or you can assume shared access to another namespace, as discussed above.

2) There are several general approaches to handling tabular data in vocabulary design. Before reviewing them, it is important to remember the lessons learned form relational database theory about tabular data. The ordering of rows shouldn't matter, the ordering of the columns within a row shouldn't matter, no repeated column names, in other words a third normal form structure (at least). Even if the native DB isn't normalized, the transfer syntax can be.

Naive XML:

In naive XML, only tags are used.

<row>

<col1>value</col1>

<col2>value</col2>

<col3>value</col3>

</row>

</table1>

It works, but it is hard to enforce (via DTD) the constraint of

unordered, unique columns. Values in element content mean that large blocks

of text or markup may be stored. This may be considered good or bad.

Canonical XML

In canonical XML column values are stored in attributes.

<table1

col1="value"

col2="value"

col3="value"

As Bosworth and Layman point out in their "Serialization of Graphs

of Data" paper, XML attributes have many of the same constraints as columns

in a database table. They are unordered. They must be unique. They cannot

contain markup. The last is similar to columns in an RDBMS only containing

'atomic' data. This syntax is straightforward and compact, and to my mind is

preferable in situations where the 'shape' of the data in known a priori.

Notice also that there is no container element. None is needed.

Generic table model

HTML is an example of a generic table model. Any table of data may

be represented at the cost of a level of indirection.

<tr>

<td class="col1">value</td>

<td class="col2">value</td>

<td class="col3">value</td>

</tr>

</table>

XBRL group model

XBRL combines pieces of the above models. It is a generic model which uses the group element the way HTML uses 'table' and item the way HTML uses 'td'.

<item type="col1">value</item>

</group>

The above group is one row of data. I like to think of it as

canonical XML with a level of indirection. This is consistent with the

design of XBRL which factors out the intellectual structure of the data from

the document structure of the instance. A normalized database does the same

thing.

I think it is a fault of the current version of the spec that there is no

discussion of tabular data and the 'best practice' of how to represent it in

XBRL.

COMMENT #2

From: Kit Leuder

Subject: XBRL Draft Review Comments

Date:          09/20/00     2:42 pm

Major comments:

The document has imprecise specification of normative requirements, in terms of what is the essential compliant behavior ("should", "must").

MITRE recommends that the keywords "MUST", "MUST NOT", "REQUIRED",

"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and

"OPTIONAL" be used as described in RFC-2119.

http://www.normos.org/ietf/rfc/rfc2119.txt

Section 3.13, "The group element". MITRE is glad to see the introduction of the concept of tuples (related elements, such as in a table row), since MITRE's past review of the XBRL 2000-04-04 version indicated that the inability to present table data was a serious shortcoming. Unfortunately, this section is vague in distinguishing between which grouped items form related tuples, and which 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."

MITRE suggests that 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, such as: "If the immediate parent group contains a type attribute, and if each item contained in that group contains a type attribute with a different value than that of the group type attribute, the items form a tuple. If the immediate parent group does not contain a type attribute, the items contained in the group are not a tuple. If any item in the group does not contain a type attribute, none of the items in the group comprise a tuple."

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. It would be much better instead 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.

Other specific comments:

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

Section 2, "Group" definition. It states "In XBRL, a group is a set of related items..." However, Section 3.13, "The group element", states:

"The group element is the generic container element of the XBRL

vocabulary. ... The group element provides a convenient way to group similar items together..."

So Section 2 definition indicates the items are related, but Section

3.13 merely indicates that the items are similar (not necessarily related). MITRE suggests that the Section 2 definition be changed, replacing "related items" with "items that have some attributes in common".

Section 5.3, "The Parent-Child relationship", Second sentence. It

states: "Whatever structural relationships as might be desirable in an

XBRL document instance are captured in rollups." Note that relationships

are also captured through the use of the group to indicate a tuple, to

indicate a table-row structure.

Some comments of an editorial nature:

Section 3.4, "Type", first paragraph, third sentence. Repeated word "is

is" in sentence "A convention followed in the XBRL.org US GAAP C&I

taxonomy is that the name of a type is is a dot-separated pair of

camel-case identifiers representing a human readable name for the

concept and its parent."

Section 4.5, "Reference", next to last box of the example. Remove the

space after the colon, so that xbrl:reference is not separated:

<xbrl: reference name="SAS" number="1" chapter="530" paragraph="3"/>

Section 5.4, "Data Integrity and Confidentiality", second sentence.

"XBRL deliberately provides neither of these mechanisms, since its focus

is on transmission of actual financial content in an agreed-upon format..." XBRL has nothing to do with transmission, but rather with document encoding or representation.

NO RESPONSE

COMMENT #3

From: Kit Leuder

Subject: DRAFT, Additional Comments on XBRL for Defense Finance Accounting Service (DFAS): Clarification on XML parser inability to parse XBRL documents

(Not a coordinated MITRE position.)

Date: 11/17/00

First, here is an overview of an XBRL-encoded financial statement instance, in the file "DFAS DoD AF.xml" in the attached zip file. In this instance, it has one "group" element as the root tag, which defines the common attributes for the entire instance document. It then has another "group" element to describe one column of the financial report table; in the first case it is for entity="DOD:AirForceActive". Then there are a series of "item" elements, which can be provided in random order, describing the information for each line-item of the financial report, with an attribute of "type" to identify 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) does not know what to do with this, and cannot process the financial information properly. This is because it does not know how to process the externally-defined schema taxonomy file, which is given in "schemaLocation" attribute. The generic XML parser does not know that the following are line items that pertain 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, it doesn't know that the following are line items that pertain 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 parser would be told of the association explicitly based on the XML element hierarchy nesting, so it wouldn't have to go to an external taxonomy schema to determine what data went where.

Also, if the XML document contained the totals, it wouldn't have to know 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 parse an XBRL document. However, it wouldn't require many changes to the XBRL specification to enable parsing by a generic XML parser.

First, if XBRL allowed a group attribute of (for example) "related", and allowed all the enclosed "item" elements to be related to each other, you could include a group specification within an XBRL instance document:

(a list of assets-related line items goes here)

</group>

(a list of liabilities-related line items goes here)

</group>

Second, if XBRL permitted the inclusion of sub-totals, at the end of each of these groups

then the XML parser would be able to pick up the totals without having to compute them.

Thus, with minor changes to XBRL specification, the data structure and nesting would be provided to the parser (from the <group related="xxx">), and the totals computation would be provided (from the <item type="generalTag.total">). This would enable the XML parser to be able to process XBRL documents without having to go to an external taxonomy document. These are rather trivial changes to the XBRL specification, with significant benefits to the XML community.

Kit Lueder,

MITRE.

RESPONSE #1 to COMMENT #3

From: David Vun Kannon

Date: 11/22/00

Both of Kit's suggestions are already doable within the current spec. However, neither of them are _required_ ways of structuring documents. DFAS could choose to mandate these suggestions as a "internal style guide", but there are some implications, of course.

Suggestion

1 - allow group elements to show that all included items are related to a higher level concept

This can be accomplished by adding a type attribute to the group element that identifies the higher level concept.

Implication: We know in advance which levels of grouping are important and which aren't, and which taxonomies are in use.

2 - allow XBRL instance documents to include items that represent totals.

This can be accomplished by including in the document an item element with an appropriate type and content.

Implication: There may be discrepancies between totals and other content, and our programs know what to do in those cases.

In general, Kit's comments do not make certain valuable distinctions.

An XML parser can only verify that the XML syntax is respected, not that the meaning (the semantics) is correct. So it is inappropriate to say that "A generic XML parser ... does not know what to do with this, and cannot process the financial information properly." A parser never "knows" or "processes" anything about any XML document at the level of its meaning - in the case of XBRL, that the document is financial information. At best, a parser verifies the correctness of the syntax of the document and passes a memory structure (the DOM tree) which corresponds to the document to another piece of software.

That other piece of software is something that does "understand" the document. It has to be written by people that understand the domain of financial information and the syntax of XBRL. This software, as all systems, has to make choices and assumptions about the input it will receive. It can assume that all the data will be neatly laid out and totaled by some other upstream process, for instance. Fine, that shifts the burden of certain checks and procedures to that upstream process, but if that is how the division of labor works among those systems, it is perfectly acceptable. It is unacceptable, in my view, to never do those checks and proceed on blind faith in the quality of the data.

The DFAS demonstration included a whole pipeline of processing, during which the XBRL documents underwent significant processing and transformation. Several of the initial steps in that pipeline correspond to the "upstream" checking I refer to above. They bring in the taxonomies, create the hierarchical grouping, and do the totaling - all so that subsequent steps can operate with certain simplifying assumptions about the data. The initial steps can be leveraged and reused by different downstream processes.

Because we were providing the entire pipeline of processing, the input documents were designed in a very lean way. Only the essential information was provided, basically a database dump. This style of document was chosen because it highlights the power and versatility of XBRL, as well as showing that programs that understand XBRL (and do interesting work) are short and for the most part straightforward.

It would have been trivial to create XBRL documents that paralleled the desired HTML presentation. That would have proven nothing about XBRL, or its usefulness to DFAS.

Cheers,

David vun Kannon