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] Issues for v2.0 of position paper


Another aspect of standard development as broad as tax is a repository of
schemas, artifacts, code lists. Moreover, the ownership and maintenance of
these will be critical as well. I am certain that tax administrations and
private enterprises will have vested interest in establishing and
supporting such a repository.

Any thoughts on this are welcome.


Michael Roytman.

|         |           marc.van.hilvoorde|
|         |           @nl.pwc.com       |
|         |                             |
|         |           07/08/2004 08:28  |
|         |           AM                |
|         |                             |
  |                                                                                                                               |
  |       To:       tax@lists.oasis-open.org                                                                                      |
  |       cc:       "'Andy Greener'" <andy@gid.co.uk>, <swebb@gefeg.com>                                                          |
  |       Subject:  RE: [tax] Issues for v2.0 of position paper                                                                   |

My thoughts on the current discussion

I think there are more levels to discuss on the transport or security
aspect. If I elaborate on your truck example

You can make a choice for a car/truck to deliver packages
You can tell people to take a specific route or road
You can tell people if you take that road, please be careful and keep you
speed limited to 60
You can act like the police and check if everybody is driving according to
the rules

My point here: I also think that transportation is less relevant, but
transportation is linked to security. And i do think security is relevant.

The question is: do we need or want security?
If yes: who wants it, who is responsible? Everybody, so nobody?

If my bank opens an office in a very bad neighbourhood (and the internet is
not a safe place!) and asks me to bring my money (tax data), can I hold the
bank responsible for my safety?  Probably not, and that is why i do not
carry much money with me and go to another bank. With tax filing i do not
have much choice. And may be tax regulators will consider the safety of the
people and feel at least a bit responsible for helping people to bring
their money.

What is security? "People should be able to send their packages (tax data)
and get confirmation on:
The package was received by the right party, in time and in the same order
as it was send. "

F.i. the CobIT framework can be considered as an open standard to achieve
these purposes.  I am not trying to complicate things, more connecting. The
group should decide if the connection is relevant. If the goal of this
group is to connect different standards (and make choices) to enhance the
tax filing process (and make it more easy for the 'clients'), then security
can be part of the discussions, i think.

A starting point for further development could be the model on page 16 of
the position paper. Would it add value to reconsider this model and add
more details (I have seen some pretty impressive models in the group, and
these are not part of the document, unfortunately), f.i. the layers Andy
mentioned in his email?
The way i see it: if the group evaluates different standards, this implies
the existence of norms for the actual assessment.  The filing process
should the basis of that. There is some material in the position paper, but
not very explicit.

The model could force you to take an explicit standpoint  (just examples of
what i am trying to make clear)
"Our tax organisation never wants to be dependent on one standard, unless
it is open."
"We never want to use just one standard, open or proprietory."
"We find we are responsible for the process starting at A and ending at B."
The same with levels in the process.
"Whe like the standards we use to have as minimal overlap as possible"
"CHoices between as little standards as possible against the best of breed"

"Try to use as much as possible exisiting business reporting infrastructure
in companies"
"Try to convince as much software vendors to participate"

Met vriendelijke groet / best regards,

Marc van Hilvoorde
PricewaterhouseCoopers Accountants N.V.
Global Risk Management Solutions

tel.: +31 (0)30 219 1706

   "Sylvia Webb"                                                          
   <swebb@gefeg.com>                 To:        "'Andy Greener'"          
   07-07-2004 22:11          <andy@gid.co.uk>, <tax@lists.oasis-open.org> 
   Please respond to swebb            cc:                                 
                                     Subject:        RE: [tax] Issues for 
                             v2.0 of position paper                       

-----Original Message-----
From: Andy Greener [mailto:andy@gid.co.uk]
Sent: Monday, July 05, 2004 9:33 AM
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
the next version of the Position Paper to be discussed on this list. This
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
interest. However, the world is not ideal and practical transport
restrictions do sometimes intrude. For instance, in the real world there
often practical upper limits on the size of messages (no use trying to
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.
==>Webb: I agree

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

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.
===>Webb: There is another generic message that is in the approval process
at UN/CEFACT called the Standard Business Document Header. It was sponsored
by UCC but has gained the interest of other industry groups. It is at the
application level not the transport level and may need to be reviewed as

(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
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
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
key part in the choice of applicable standards.
===>Webb: I agree.

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
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.
===>Webb: I agree. Further, how ebXML Core Components are being implemented
in UBL, OAGIS, and CICA are different.  As an example, UBL is trying to
become harmonized with UN/CEFACT ATG2 for both Core Component Types and
OAGIS and CICA are only adopting CCT's.  What does this really mean from a
message design and standards adoption prospective?

IMHO, we also need to explore what the pros and cons are of creating
standard versus adopting an existing one.
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 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
OASIS TC), go to


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any

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