[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]