Subject: Re: Special note for CPP members
Duane, I'm glad we are beginning to converge on this. Regarding: The problem many people are starting to see is that Vendor A and vendor B need to have a definition of what the correct CPA should look like given two CPP's as input. More than likely, the two tools will produce two different CPAs unless there is a specification or set of rules (perhaps in the non normative section as you suggested) to guide the vendors. It is the "same procedures" wording that causes the majority of concerns. What are those "same procedures" and where do I find them if I am building a CPA negotion engine? The key question is whether two different tools will produce EQUIVALENT CPAs. If the TP team does its job successfully, it should be quite clear from the specification what has to be in a given CPA composed from two CPPs. This is one area where comments from the tool designers directly to the TP team will help us to get it right. Differences between equivalent CPAs should be in inconsequential areas like reordering elements or attributes whose order doesn't matter. Remember that the two Parties should be installing identical copies of a single CPA, not producing separate CPAs from the same pair of CPPs. The latter is doomed to failure. Aside from the additional complexities, unless both parties install identical copies of a CPA signed by both of them, they never can be sure that the two copies are truly identical. Regarding: It is the "same procedures" wording that causes the majority of concerns. Where is this discussion of "same procedures"? I can't find it in either the current CPA-CPP specification or the TA specification. It sounds like a statement that needs work. If you tell me where it is, I will do something about it. Regarding: Should Karl set up a separate list for this subject or should it be a thread under the main CPP group? Any discussion on the composition/negotiation topic needs to be in view of the whole TP team, so there is no (if not negative) value to keeping the composition/negotiation discussion separate. Remember that the first goal must be to guide the CPP-CPA specification into being complete and precise enough such that any pair of CPPs that specify compatible function can be composed into a correct CPA by anyone's tools. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* Duane Nickull <duane@xmlglobal.com> on 01/30/2001 02:22:52 PM To: Martin W Sachs/Watson/IBM@IBMUS cc: matt@xmlglobal.com, Scott Hinkelman/Austin/IBM@IBMUS, "Welsh, David" <David.Welsh@nordstrom.com>, "Bob Haugen (E-mail)" <linkage@interaccess.com>, "Brian Hayes (E-mail)" <Brian.Hayes@Commerceone.com>, ebXML-StC <ebxml-stc@lists.ebxml.org>, ebxml-tp@lists.ebxml.org, Brian Eisenberg <BrianE@DataChannel.com>, Mike Rawlins <rawlins@metronet.com> Subject: Re: Special note for CPP members Marty: Some comments inline: Martin W Sachs wrote: > > Duane, > > First and foremost, the place for placing requirements on a team to develop > new functionality is the ebXML Requirements specification, not the TA > specification, so you need to communicate the desire for these requirements > to the Requirements team. The TP section of the TA document thus far is an > exposition of the architecture and any words you put in should continue > that style. Agreed. > > Given any work on negotiation protocol today cannot possibly be in time for > ebXML Version 1, since the deadline has already passed, any prescriptive > words that you put in now about negotiation protocol will be empty, so > putting anything in will mislead the reader into thinking that the function > exists when it doesn't. The place for prescriptive words is in the version > 2 TA specification if ebXML continues to exist after May. >>>> This is a good suggestion. > > In addition, the whole question of whether it is appropriate to define a > normative composition and negotiation procedure at all is a major issue > that needs much wider discussion in ebXML. Since the very first standards > (plumbing parts 100 years ago if memory serves me correctly), standards > have focused entirely on interoperability and have avoided constraining > implementations. There are no interoperability issues in CPA composition > and negotiation as long as both CPPs conform to the ebXML CPA-CPP > specification. Any tool that produces the correct CPA works regardless of > whether vendor A's tool uses the same procedures as vendor B's tool. >>>> The problem many people are starting to see is that Vendor A and vendor B need to have a definition of what the correct CPA should look like given two CPP's as input. More than likely, the two tools will produce two different CPAs unless there is a specification or set of rules (perhaps in the non normative section as you suggested) to guide the vendors. It is the "same procedures" wording that causes the majority of concerns. What are those "same procedures" and where do I find them if I am building a CPA negotion engine? There is obviously a lot fo work to do in this area still. The suggestion to have a small group of interested people participate in an online discussion is excellent. Several people from XML Global are committed to provide input. I am sure that others are anxious to contribute as well. Under your groups leadership, maybe they will be able to put together more than a few paragraphs for the CPP/CPA spec due out in May. > > If you nonetheless want to put something in now, it should be something > like this: > > The CPA-CPP specification includes a non-normative appendix that > discusses CPA composition and negotiation and includes advice as to > composition and negotiation procedures. >>>>>>>>> Okay - we will use this wording. > Also, please spell "Collaboration" correctly (NOT "Collaborative"). Oops - my bad!!! Should Karl set up a separate list for this subject or should it be a thread under the main CPP group? Duane NIckull
Powered by
eList eXpress LLC