RE: [tax] Issues for v2.0 of position paper

["Peter M. DeCastro" <pdecastro@mitre.org>]

Andy,

Here are my contributions to the discussion.

Transport:
I agree with your first thought. The mode of transport (HTTP, SMTP, BEEP,
FTP, Tape, etc) for the Tax XML documents should not be a concern for the
committee. The strengths and weaknesses of each is readily available on the
Web. If we want to add value to the whitepaper an appendix with 'well known'
transports and references could be added.

The last sentence has some interesting concepts. Dictating a transports
minimum supported sizes for a "message"(a term yet to be defined for Tax
XML) and developing a framework to support it could be a significant effort.
Perhaps recommending the use of 'appropriate' standardized transports and
compression tools would be a better path.

Message Format:
As I indicated before there is no definition of a "message" for Tax XML. The
term message is often defined in industry as containing a header (which
stores control information about the message) and a payload (the actual
content of message). The 'fun' part would be trying to define a set of
standard formats and contents for the header and payload of Tax messages.
Whether the committee decides to tackle the Tax message framework or not, it
should define the context of the term "message" within Tax XML for the next
version of the whitepaper.

** XML size:
This is an on going concern of the XML community not just with transport but
the efficient parsing and storage of the XML documents. The size of an
instance document can somewhat be influenced by converting elements to
attributes (where appropriate), abbreviating element and attribute names,
and stripping out insignificant white space, to name just a few. Given the
amount of raw data in many XML documents the effect on the over all size may
not be significant.
Trying to design a XML instance document framework to allow 'chunking' has
many pitfalls and probably should be avoided. Let the implementers of a Tax
XML exchange do it if they so desire.  

Security:
I agree that security of the Tax message session is something the committee
should avoid. Within the payload there may be a requirement for digital
signatures or some other means of authentication on a per document basis.
Perhaps the document framework should accommodate this as possible
requirement?

Web Services:
If the focus of Tax XML is the payload of tax documents then whether it's
delivered in a Web Service or FTP of a file shouldn't matter.

Document Structuring:
I see this as the core of the Tax XML effort. When a standards framework is
developed we should provide example cases for building instance documents in
an appendix of the paper



Peter 

-----Original Message-----
From: Andy Greener [mailto:andy@gid.co.uk] 
Sent: Monday, July 05, 2004 12:33 PM
To: tax@lists.oasis-open.org
Subject: [tax] Issues for v2.0 of position paper

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

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
.