- From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
- Date: Fri, 28 Feb 2003 10:49:37 -0600
- To: bhaugen <linkage@interaccess.com>, "Assaf Arkin" <arkin@intalio.com>
- cc: www-ws-arch@w3.org
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.
Received on Friday, 28 February 2003 12:33:32 UTC