Perhaps the question is: what is it that you are hoping to represent in
that table, and why use XBRL, in particular, for that purpose?
I. What is XBRL and is it appropriate for representing "random" tables?
XBRL is XML optimized for business reporting.
XML is all of the content and all of the context necessary for
presentation without being tied to one presentation format. A table is
just one presentation format for multidimensional data.
XBRL is an agreement in advance on representing a number of dimensions
common to business reporting. Your primary taxonomy, in general, would
not have to include common dimensions such as:
- Reporting dates or periods,
- Companies and their departments or reporting units,
- Reporting scenarios, such as Actual, Budget, Forecast, Projection, or
- Units of measure
The Specification
These dimensions are formalized by the XBRL Specification (see
http://www.xbrl.org/Specifications/). Special tools, called Dimensional
Taxonomies, can serve as the collection and validation points for some
of these dimensions, but that is usually a separate issue.
Existing Taxonomies
In addition to the Specification formalizing in advance typical
business reporting dimensions (often the values to the columns in your
examples), existing XBRL taxonomies may already have the
representational power to collect that data you would like to show. For
example, XBRL GL, the standardized Global Ledger
(
http://www.xbrl.org/GLTaxonomy/) is an existing taxonomy that can
represent the underyling details you would find in business operational
and accounting systems (accounts receivable, accounts payable,
purchasing, customer order entry, inventory, job costing, payroll,
fixed assets and, of course, general ledger.)
Your tables may just be "pivot tables" from the underlying information
in XBRL GL. For example, if your tables represent (Table 1.) customers
and customer categories and (Table 2.) inventory items and product
categories, XBRL GL already defines how to represent all of this
information, and you would just run it through a stylesheet to
summarize the data in the table format.
Agreement with others has advantages
There are a number of existing software applications that have been
developed to understand the XBRL Specification, existing financial,
tax, and banking taxonomies and XBRL GL, and so make reuse of data
published in XBRL format easier. It also makes populating the table
from existing systems simpler.
Devloping custom taxonomies, custom linkbases and linkroles and using
XBRL for purposes that it was not anticipated for means you won't be
leveraging the power of agreement, although you would be able to use
existing XBRL taxonomy and instance tooling for your work.
With all that background on why it is important to think through the
semantic meaning of your tabular information, and see if XBRL is the
optimal tool, there are a number of ways to totally abstract XBRL to
the physicial placements and formats of your tabular example. Is your
case as simple as it looks below? Eight items you want to present in an
instance, and the taxonomy would hold the relationships?
You can define concepts A through H, as well as each of the row and
column concepts, in a taxonomy. You can use Definition links
(general-special, perhaps) to associate each item (A through H) with
both the row and column it is associated with. You can set up each
table as a Custom Role Type, and then use presentation links to put the
right elements within the right table.
In a more elaborate/flexible environment, you could
1. Set up a small taxonomy with
a. Defined elements
TABLES a tuple to hold the TABLE and rows information
TABLE, data type integer to represent the 1 and 2 of TABLE 1 and TABLE
2 (or other datatype and identifier of your choice) or separate TABLE
elements if you wish to hard code the tables
row 1 with appropriate data types for the data being stored, such as
string
row 2 " "
....
row n " "
b. Presentation and Definition links that place/associate the row
under (the appropriate) TABLE
2. A Dimensional taxonomy with the dimensions you want for col1 and
col2
And then create instance documents that have the tables and rows as
items and the dimensions in the contexts.
If you feel like sharing more details, we can talk more about how to
use XBRL to represent the data.
<eccn />