tpaml concerns

[David Burdett <david.burdett@commerceone.com>]

Firstly

Many apologies for being out of the loop for so long on TRP activities, but
I am just beginning to surface and have had opportunity to go through the
tpaML spec and the several emails around it.

Although I think agreement of the conditions or contract between the parties
involved is an important part of carrying out eCommerce. I really think that
the current structure of tpaML is not the best way to do it.

In outline my concerns (which I expand on below) are:
1. the current tpaML contains multiple sections of a contract that should be
separate documents
2. we're defining the terms of a contract before we know what we want to
agree (i.e we're putting the cart before the horse)
3. making TRP dependent on a pre-existing tpaML will cause a barrier to the
use of TRP
4. the current data elements need to align with core components work.

More detail is provided below. I'd be happy to go through these on the
conference call today.

If any of these points have been covered previously in the F2F then I
apologize.

David

tpaML HAS TOO MANY FACETS
=========================
The current tpaML document contains sections that describe:
1. The business process and document exchanges
2. How the documents in the exchange should be transported.

I really think that these should be defined separately as they will
frequently be independent of each other. For example a company could have:
* a standard method of doing a business process that could work over many
transport protocols, and
* several different methods of transporting the messages associated with
that business process.

This will lead to replication of the business process definition and/or the
transport rules that are not required. It could also result in
inconsistencies in definitions.

I think we need to:
a) create separate specs for each section of the existing tpa spec where
each defines a subset of the total tpa that *has* to be negotiated at the
same time
b) specify a very short "full tpa" spec that defines how to link previously
agreed sections together
c) develop a separate "negotiation" business process spec that defines how
to negotiate any of the above - this though should be done by the BP team

To draw a data modelling analogy, the current tpaML spec is "unnormalized"
whilst the actual data itself should be normalized.

Further benefits of separate specs are:
a) we can separately revise each part of the tpaML spec, so for example if
we want to change the transport related aspects of the spec we can do so
without changing the business parts and vice versa
b) in the instance, two parties can negotiate a changed or improved business
process without having to re-negotiate the transport, and vice versa.


WE'VE PUT THE CART BEFORE THE HORSE
===================================
When I look through the tpaML spec it seems to make many assumptions about
what is required to support TRP or BP.

I find this hard to accept when we haven't even finished the TRP spec yet.
Until we do, we won't know what we will need to negotiate. For example in an
earlier version of the header spec, we included the idea of message routing
history. We might (or might not) put it back in. If we do, it's quite
conceivable that the maintenance of a routing history might be a
configurable item in which case it needs to be agreed between the parties
involved and therefore part of the tpa.

The point I'm trying to make is that we can't work out what should be in the
agreement (and therefore the tpa) until we know what we need to agree.
Secondly, only the group that is working out what needs to be agreed can
specify what goes in the TPA anyway.

So what I think we should do is:
a) develop separate tpa sections for each area (see previous comment)
b) place responsibility for developing each section on the part of ebXML
that is developing it, e.g. TRP for transport, BP for business process, etc
c) develop the specs for each tpa section as part of the development of
activity of the appropriate working group

WE'RE CREATING A BARRIER TO THE ADOPTION OF TRP
===============================================
Firstly if tpaML remains monolithic (as currently defined) then it means
that TRP can ONLY BE USED AS PART OF A BUSINESS PROCESS. This just doesn't
make sense as sometimes you just want to send a message reliably to someone
and get a response back.

Secondly in many instances, there will be standard "agreements" on how to
send messages that do not need any pre-agreement. For example, if we want to
send an email we don't agree in advance with someone that if they don't
reply we will resend the message, but if they've already received it they
should ignore it.

I am very firmly of the belief that it should be possible to do TRP without
having to agree a tpa first.

To solve this problem, what I think we should do is:
a) predefine a number of "standard" tpas for transport purposes and give
them standard identifiers
b) allow messages to be sent, without prior negotiation or agreement,
provided they reference  one of the predefined tpas
c) if the recipient of a message cannot handle the predefined tpa, then
reject the message with an error

ALIGNMENT WITH CORE COMPONENTS WORK
===================================
This has already been covered by other emails but I also think it important
that element definitions inside the tpa adopt the structures developed by
the Core Components group.

Product Management, CommerceOne
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599 
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com