Comments on XML Position Paper

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

Below are both general and specific comments on version 0.3 of the
XML Position Paper for Tax Administrators. It's possible that specific
comments may be rendered irrelevant if major changes are made as a result
of the general comments, but I'm including them all anyway.

General comments:

1. The document needs to be positioned with respect to its intended
audience (and that audience needs to be clarified). I think that the
title is correct (as far as it goes) in addressing the document to
Tax Administrators (or Tax Administrations...), but we know that it is
also targeted at OECD. It's not clear to me whether that should be
explicit in the title or not (I leave it for others to decide whether
'Position Paper' is appropriate or not - I have no strong views on
the subject).

Having got the audience sorted out, we then need to position the document
correctly for that audience. At the moment the Recommendations sections
are aimed at the Tax XML TC itself. It would be more appropriate for the
recommendations to be addressed to Tax Administrators/Administrations
(suitably modified of course), but perhaps with a statement of the TC's
current and future intentions in close proximity to provide context and
justification for each recommendation (i.e. we practice what we preach).


2. We need to be careful to make the distinction between XBRL the standard,
and XBRL the federation of jurisdictional Taxonomies. The standard is an
empty vessel as far as specific data items are concerned, so it is not
appropriate to talk of XBRL as defining some tax reporting items but not
others - the standard itself doesn't define any data items. Data item
definition is the domain of the Taxonomy builders in each jurisdiction,
and inevitably there will be differences in coverage (and in terminology,
and appropriateness, etc). We need to take care when justifying XBRL as
a standard that we don't rely on any particular Taxonomy - in fact it's
entirely possible (as we discussed in the first XBRL SC call) that we may
be instrumental in formulating an international tax XBRL Taxonomy upon
which jurisdictional Taxonomies might depend or make reference to (once we
have our Global Tax Ontology in good shape).

I'm also a little nervous about recommending XBRL wholesale as the standard
for tax reporting. It is certainly appropriate in the corporate financial
reporting world, and by extension therefore the corporate tax reporting world,
but I can think of a number of tax reporting scenarios here in the UK for
instance for which it would be less than ideal (personal tax compliance
information, payroll deduction and compliance information for income tax and
National Insurance, duty on property and financial transactions, etc).


3. I don't think that enough emphasis is being given to UBL - as we
know it's not just a supply chain standard, but equally it's not just
an alternative to CIQ or other standards for customer data either. It
provides a framework in which document templates can be defined and
combined with re-usable components to produce structured documents that
follow a well-defined set of compositional rules. Individual components
may be built with other standards, such as CIQ or even XBRL, as appropriate.

The same argument could be advanced for the OAGis document framework,
which is very similar of course.


4. Given that OASIS is largely an XML Standards body, and the title of
the TC is 'Tax XML', it seems a bit superfluous to suggest that the committee
has actively selected XML (Executive Summary) as the preferred standard for
exchanging information. I think that was a 'given' :-)

5. The sense and meaning of various sentences needs to be reviewed in the light
of an apparent 'find & replace' of "ATO" (singular) with "Tax Administrations"
(plural)!


Specific Comments:

1. Glossary: Browser channel: I don't understand this definition at all - 
is it the result of a global 'find & replace' for ATO?

2. I'm not sure I understand the difference between the definitions for
'online interactions' and 'Other software channel' - they seem to amount to
the same thing.

3. Glossary: TaxXML: Any Tax XML standards that emerge will not be limited
to the exchange of data between central tax agencies.

4. Glossary: UBL: UBL is not "an XML Schema" - it's better described as
"a template and component framework for business documents". It's not
restricted to documents such as Order, Invoice and Despatch Note either,
though those are the document types the UBL TC have implemented first.

5. Glossary: XML Document: the term 'statement' carries too much baggage
I think, and whilst an XML document is text, I think "text document" is
also  misleading. I'd prefer: "A self-contained stream of XML-formatted
data such as a message or a company's financial details".

6. Glossary: XML schema: A Schema can describe a part or a fragment of
an XML Document as well as a complete definition (i.e. an XML Document
may be fully described by a number of XML schemas).

7. Executive Summary: The sentence "These are but some of their challenges"
is superfluous.

8. Executive Summary, 4th para: drop the word "future" - XML is preferred
now! (but see my general comment (no 4) about this whole para).

9. Background 1.1: I don't understand what 'the Tax Administration's
E-Service results' means in this context.

10. Document Purpose 1.2: The second bullet point is not appropriate
since it isn't a question (and that only leaves one bullet).

11. What is Interoperability? 2.1: change "ability of two systems" to
"ability of two or more systems".

12. Standards coverage 4.2: I think there is an important piece of
content missing from the diagram: compliance data. In "self-assessment"
regimes particularly, compliance data is an important component of a
return - it's not financial data, and it's not "client" data (which  might
be better termed "designatory" data anyway).

13. XML Value Proposition 5, Externally 5.1: Despite being titled the
"XML Value Proposition" this section is entirely oriented towards XBRL
and corporate taxation.

14. XBRL 5.3: Specific examples from the Australian jurisdiction need
to be removed from this section and the difference between the XBRL
standard and local accounting taxonomies made clear (as discussed in the
general points above). Also, there is a factual error that needs correcting:
UK IR have not, as yet implemented any e-filing applications using XBRL, but
we're working on it :-)

The last sentence (before the Recommendations) doesn't make sense.

15.  Recommendations 5.3: Qualify support for XBRL for "exchange of
*corporate* financial information". The recommendations are for the
TC, not the target audience (as discussed in the general comments above).
The last bullet point should refer to extension Taxonomies to existing
XBRL Taxonomies, not "schemas".

16. UBL 5.4: 2nd para is misleading - UBL is not just applicable to data
such as client details (see general comment above).

17. SAF 5.6: The third para seems to start mid-sentence?

18. Recommendations 5.9: UBL: the UBL TC won't address tax documents if we
do nothing, so we need to be more pro-active than simply "monitor progress
occasionally".

19. Recommendations 5.9: diagram: same comment applies as for point 12
above - compliance data is another important component. UBL and/or OAGis
are potential standards for the "content" component in the diagram (i.e.
the structure and organisation of the document).

20. Attachment 1: XBRL: again, this needs to clarify the separation
between the XBRL standard and jurisdictional Taxonomies. The bullet points
in particular refer to specifics of a particular local Taxonomy.

The last para of the attachment is a little mis-leading - "scaremongering"
about the complexity of XBRL was propagated by an industry representative
body, without any real evidence from their members, and I'm not sure what
the relevance of UK IR accepting PDF documents is in this context. Perhaps
it's better to remove this para?

21. Attachment 2: UBL: It's not really accurate to speak of "one UBL schema
for common business documents" since UBL defines a framework for document
templates and re-usable components which may involve many individual XML
Schemas in the composition of a document.

22. Attachment 4: SAF: The last sentence of the 4th para (just before
'Advantages') doesn't make sense here (it looks like it has been translated
into English and may have been dropped in out of context).

The section on 'Compression and safety keeping' also seems out of place
here.


	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