RE: revised requirements

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

Dale

Thanks for your comments. Responses inline.

David

-----Original Message-----
From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
Sent: Sunday, September 10, 2000 2:57 PM
To: Burdett, David; Martin W Sachs/Watson/IBM; ebxml-tp@lists.ebxml.org
Subject: RE: revised requirements




> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Saturday, September 09, 2000 12:43 PM
> one general issue that I raise that I would like to repeat here ...
> 
> <snip>
> Do we want to restrict the TP groups work to just business 
> relationships.
> Electronic documents can be sent between two parties when there is no
> "business" relationship. Particularly, the functions in the 
> ebXML Messaging
> Services spec, e.g. reliable messaging, equally apply to business and
> non-business situations. If we wish to restrict our usage to 
> ONLY business
> relationships then using the term Trading Partner is fine. If 
> we don't then
> we should replace the tern "Trading Partner" as used in 
> Trading Partner
> Agreement and elseweher by something more neutral such as "Party" (see
> definitions below).

David,

Is the issue here that some exchangers of documents may not actually
be trading partners? (That is , they may be marketplaces, hubs, vans
or whatever?) 
<db>
It all depends on what you mean by a "trading partner" we're using trading
partner very loosely IMO to mean either a someone you do business with at
one extreme or somone you want to send a message to (whether business
related or not) at the other.
</db>

Or do you want to open up the scope of this so that mailing lists,
anonymous ftp sites, my PPM access to CPAM perl modules, and all
other web based document transfers become part of 
the tasks for ebXML TPA WG? 
<db>No this isn't my intention. Trading Partner Agreements between
businesses for the purpose of doing eCommerce is a completely valid use
case. I just think that sending a message reliably from one party to another
is a real requirement that applies to business and non-business situations.
I just don't want to so contraing the Transport Routing & Packaging work so
that it can only be used to send messages reliably between businesses who
have a pre-agreed method of trading. If we do, we are excluding the benefits
of the technology from the rest of the world who's "not interested in
business". In a way it's a bit like email. Many people use email for
exchanging messages about their work with their "trading partners". It is
also used though for sending messages to your relatives about what you did
over the weekend. Imagine what it would be like if you could only send an
email after you had agreed the business process you were going to
follow.</db>

If we open
up the scope much beyond ebXML message services, 
I think this is going
to become a general web service discovery initiative, 
like UDDI and other service directory efforts.
Why repeat those?
<db>I have no intention of repeating these efforts. My objective has always
been to try and get one solution that is generally applicable (i.e. it can
be used in many different situations) rather than a solution that is focused
on a particular scenarioe (e.g. B2B eCommerce).</db>

I do not want to discourage precise usage of language and reasonable
diction, but "trading party" is far from neutral in its connotations;
to me it still suggests economic transactions of some sort (but maybe
more or a Tupperware variety :-).
<db>I agree. That is why I think Trading Party needs to be defined more
precisely.</db>

Aside from the word choice problem, can you respond by
explaining the shift in the scope of effort 
that you are proposing -- this would help me understand 
this issue better. Sorry to be obtuse on this but 
I want to understand what I would be buying into here.
<db>Hopefully my earlier comments have explained where I'm coming from. Let
me know if it has not.</db>

Dale Moberg


> 
> We haven't properly discussed this as an issue but, IMO, we 
> should. If we
> can't quickly come to a consensus, I think a vote is a good 
> idea as then the
> issue will be resolved once and for all.
> </snip>
> 
> David
> 
>