Issues for v2.0 of position paper

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

During the recent conf call Harm Jan asked for suggestions/issues/
ideas for the next version of the Position Paper to be discussed on
this list. This is a shameless attempt to kick-start the discussion!

Of the issues outlined for discussion in Washington, but not really
addressed, I think we can all but eliminate a couple right away (but
please feel free to disagree :-):

Transport: about as relevant to Tax as the make of truck FedEx use to
deliver packages. We should be entirely independent of any transport
mechanisms, whether locally defined or based on standards. In an ideal,
strictly layered, world transport would be hidden well below our
boundary of interest. However, the world is not ideal and practical
transport restrictions do sometimes intrude. For instance, in the real
world there are often practical upper limits on the size of messages
(no use trying to FedEx a package bigger than their biggest truck).
Whilst we should not be trying to specify transport mechanisms we can
set acceptable parameters (such as minimum supported message size) and
design our document framework in such a way that we can accommodate them.

Closely allied to transport, and treated in the same way, are generic
message formats such as MIME, DIME and SOAP. We should not care that
tax documents (or other business documents with tax components) are
cast into particular transport-oriented message formats for transmission,
but again, there are untidy bits poking through the nice clean layers
that need to be accommodated.

Further work is needed to identify those aspects of tax domain documents
that might need special provisions in any document standards we develop
or adopt, or that might impose certain requirements on underlying transport
formats and protocols.

(We have a particular case in point in the UK: a message size limit of
25Mb is imposed by the Govt Gateway for good practical reasons, and whilst
this would be unlikely to influence the design of an invoice Schema it
does influence the design of Schemas for large tax documents that may
approach or exceed this size - eg. our largest employer produces 200Mb+ of
XML relating to annual employee payroll tax deductions and National
Insurance contributions. Use of the UK Govt Gateway is imposed upon
the UK tax administration by Govt-wide policy - it is not a choice that
the tax administration is at liberty to make, and the same will likely
be true for tax administrations in most other jurisdictions operating
within the confines of some sort of e-Government structure or framework)

Security: for the same reason that XBRL Int'l have rejected any specific
support for security from their standard, so must we. Though it is applied
to payloads, security in all its forms is not an integral part of a payload.
The term "Security" also covers a multitude of sins - including but not
limited to confidentiality, integrity, authentication, authorisation and
non-repudiation. There are well-known ways of achieving all these aspects,
and again, they are likely to be choices outside the control of individual
tax administrations - jurisdictional policies are much more likely to play
a key part in the choice of applicable standards.

Web Services: we probably need to discuss the scope of this and its
applicability before coming to any firm conclusions. It is easy to see
how recommendations in this area would be of practical use to tax
administrations - I'm just not sure I know exactly what the scope is
and exactly which way the wind is blowing in the Web Services standards
world just now.

Document structuring: we've really only scratched the surface of this
in the present paper by making no more than passing references to UBL,
OAGis and CICA. We need to be a lot clearer on where these standards
are competing or complementary (for instance, ebXML Core Components
seem to be a common thread leading to at least some convergence) and
how we might utilise them in any standards framework we recommend.

Both UBL and OAGis address indirect tax already of course within their
respective document framework definitions, and our indirect tax review
is meant to get to the bottom of the differences and produce a reference
model by which these standards can be judged, but I see the direct tax
domain as an extension of the business document structuring techniques
provided by these standards. These are two sides of the same coin: a
supply-chain business document is simply a structured business-oriented
document with some tax-specific as well as generic components, and a tax
return document is simply a structured tax-oriented document with some
generic as well as tax-specific components. Fundamentally they are
structured document templates designed for a specific purpose and
containing a number of specific and generic, re-usable, components.

I'll leave it at that for now. Please feel free to comment on,
challenge or even agree with(!) any of my statements, assertions or
assumptions.

	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