RE: [tax] Comments on XML Position Paper

[Andy Greener <andy@gid.co.uk>]

At 10:59 am -0500 12/3/04, George Farkas wrote:
>You are right that there is a great deal of tax data that is non-corporate in nature. But I am not sure that is relevant. The standard is content-independent and taxonomies can be built to work with that data as well. There may be data that neither XBRL "view reporting" (Eric's term) nor XBRL GL cannot handle, but I have not yet seen it. (As an aside, my first attempt at creating a taxonomy was for Canadian personal income tax returns.)

I don't doubt that taxonomies can be built for just about any structured
data - there'd probably be something wrong with XBRL if this was not the
case, but the question should be "is it the most appropriate standard to
apply?"

Traditionally (gosh, have we been using XML *that* long!) we build Schemas
to directly represent structured transactional data (often the structure
closely resembles that of the equivalent paper form for reasons of
integration with the data-capture functionality of existing back-end
systems, but that is just a short-term phenomenon).

W3C XML Schema and other schema languages are more or less adequate for
this purpose (not surprisingly), and it is a well-trodden path with tool
support increasingly being applied at every step. Corporate accounts and
other "business reporting supply chain" data doesn't fit this highly
structured model well; hence XBRL, which essentially provides a mechanism
for conveying data that is much more amorphous in nature (the Schema part
of a Taxonomy is essentially flat - a "list" of data items that can be
arranged in an instance document in the loose structure defined by the
generic xbrl-instance Schema and whose inter-relationships are described by
various linkbases).

But of course there are mechanisms to re-impose structure where it's
needed (tuple and group), and of course these mechanisms can be applied
to any extent, if necessary restoring all the structural rigidity that
XBRL worked hard to remove in the first place. Thus highly structured
transactions can be represented in XBRL, but would you want to go down
the XBRL path to get there when it can be done with XML Schema alone?

Well, you might want to do it to share or re-use your existing business
reporting Taxonomies (which is essentially the rationale behind XBRL GL's
approach, where GL entries do have a much more rigid structure), but outside
the corporate data domain the argument is less compelling, especially if
the alternatives boil down to creating a domain-specific XBRL Taxonomy and
tolerating the additional implementation complexity of XBRL, versus re-use
of existing data types and structural components marshalled by repository-
based tools designed to generate transactional Schemas.

The latter is where we are in the UK, and it is difficult to see what
the advantages might be in a switch to XBRL for (non-corporate) tax filing
transactions, with all the upheaval that would bring.

Apologies for the length of the reply!

	Andy
-- 

Andy Greener                         Mob: +44 7836 331933
GID Ltd, Reading, UK                 Tel: +44 118 956 1248
andy@gid.co.uk                       Fax: +44 118 958 9005