[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
An official key factor in making Dutch government decisions is the
reduction of administrative burden (I am just translating here) for
companies. The Dutch tax regulator uses the phrase: "we can not make (tax)
more pleasant, but we do can make it easier". I think that the tax paying
companies deserve the best decision from the regulators, I hope one that I
can explain to my clients to.
Regards,
_____________________________
Marc van Hilvoorde
PricewaterhouseCoopers
Global Risk Management Solutions
Andy Greener
<andy@gid.co.uk> To: tax@lists.oasis-open.org
13-03-2004 21:13 cc:
Subject: RE: [tax] Comments on XML Position Paper
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
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/tax/members/leave_workgroup.php
.
_________________________________________________________________
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]