This conversation is getting a bit cryptic, at least to me. You guys
seem to know a bunch of antecedents that may not be immediately familiar
to others. So when you get this all straightened out to your
satisfaction, could you please explain it in a little more detail for
those of us that are not exactly following?
Incidentally, I looked at the source you linked to below
(http://www.gldialtone.com/UCCformation.htm) and I find it pretty
interesting. It occurs to me that it might be amusing for someone with
a background in this sort of thing to sit down some rainy Saturday
afternoon and illustrate how the five elements of an offer (defined as
"the demonstration of willingness to enter into a contract") can be
accomplished by a Web service. I think that the definition of the
contract itself is probably beyond a reasonable present scope of Web
services (although I believe Frank has ambitions in that direction), but
perhaps "offer" is not. If someone went through this exercise (and I
personally don't feel qualified to do so or I would just do it) we could
then look at the results and see if it has a plausible home in the
architecture.
Or is this trivial?
-----Original Message-----
From: bhaugen [mailto:linkage@interaccess.com]
Sent: Friday, February 28, 2003 6:31 AM
To: Assaf Arkin
Cc: www-ws-arch@w3.org
Subject: Re: Business Protocol (was: Application Protocol Definition)
Comments interspersed.
Not trying to make this into yet another permathread,
but the distinctions I made have evidence behind them.
They are not arbitrary.
> > Here are some distinct things:
> > 1. Offer-Acceptance as a description
> > of the rules of contract formation.
> > 2. UNECE Recommendation 31, Electronic Commcerce Agreement as a
> > pretty neutral set of rules for doing offer-acceptance
> > electronically. 3. RosettaNet PIP 3A4 as a document specifying
> > a particular set of messages and signals for executing
> > UNECE Recommendation 31.
> > 4. An ebXML BPSS script describing PIP A34 in XML
> > (which RosettaNet is actually developing).
> At least in my understanding #1 and #2 are equivalent, with #1 being
any
> Joe's description and #2 being a UNECE Recommendation, but they are
both at
> the same level.
#1 is not electronic. It is the basic rules for offer-acceptance as
found in a commercial law book.
http://www.gldialtone.com/UCCformation.htm
#2 is a description of how to do #1 electronically.
> No #3 and no #4 seem to be at the same level.
#3 is a document. It is not executable.
#4 is a script meant to be executed.
RosettaNet and UNCEFACT both know the difference very well. RosettaNet
already has #3, and is working on #4.
UNCEFACT has a UML version of #3 and
want to generate #4 from #3 using production rules.
They'll also generate RDF from #3.