OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tax message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tax] Comments on XML Position Paper


At 3:29 pm +0100 14/3/04, marc.van.hilvoorde@nl.pwc.com wrote:
>I like to add to the current discussion:

Please - the more the merrier. I must say that this list has become
much more interesting now that we have some real issues to debate!

>I already mentioned the Dutch XML audit file; I did not mention that we
>also have a separate payroll audit file. Not all the information suppliers
>consider this the same 'standard', they need extra work to implement this.

This sounds similar to the UK PAYE End of Year Return, which summarises
payroll deduction information for Tax and National Insurance (NI = social
security, health and state pension 'tax') so that benefits and pensions
rights can be accumulated and apportioned correctly (effectively auditing
the employers who are making the payroll deductions and paying over
composite contributions of tax and NI).

>And this standard is just for tax purposes, we have more regulators who
>need information. If they all invent their own XML solutions, I am not sure
>this is less complex then implementing XBRL, as Andy suggests.

If the information that other regulators need falls within an existing
Taxonomy then you may have a point - defining a straightforward grammar
in XBRL (using groups and tuples) may be no more complex than doing it
in XML Schema, but real life is seldom straightforward. XML Schema quickly
surpasses XBRL's limited abilities in this regard, and XML Schema is not
even the most powerful schema language available. Whether a particular
solution is more or less complex in XBRL depends on the grammar and
vocabulary requirements, and every situation will be different. There is
no one-size-fits-all solution.

Taking the UK PAYE EOY Return as an example, our National Insurance
'vocabulary' is unlikely to appear in any existing XBRL Taxonomy (even
UK-specific ones, since it is of no interest to corporations), so as well
as doing at least as much work to represent the structural complexity
(assuming it could be done), an extension Taxonomy would have to be built
to incorporate the NI vocabulary. This is at least as much work, if not
more, than building a pure XML Schema in the first place, and what you end
up with is something more complicated than it needs to be (note that I
said "more complicated" not "too complicated" :-).

I have a sneaking suspicion that we are getting down to the fundamental
issue of how accountants and computer scientists "view" data differently.
The former take a tabular view and layer structural information on top,
whereas the latter see grammar (ie structure) as an integral aspect of
data. This debate takes other forms too: procedural programming vs object-
oriented programming describes a similar dichotomy in programming circles.
The tie-in is that pure XML is an excellent way of serialising object data
in an OO environment, and guess which programming paradigm is most often
used these days when building complex systems...

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

Yes, here too. Every time we add new regulation we try to make it as
easy as possible ;-)) (Cynic? Me?!)

	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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]