Subject: RE: TP teleconference minutes - Feb. 28, 2001
I am sorry I did not attend the conf call and, thus, did not comment on this during it. I disagree on the sentence : » 2. Multi-party collaborations can always be reduced to sets of binary » collaborations, each with a separate CPA I agree that, for V1, we assume that this is possible. But I do not think that this would account any general situation. /stefano » -----Original Message----- » From: Martin W Sachs [mailto:mwsachs@us.ibm.com] » Sent: 01 March 2001 17:32 » To: ebxml-tp@lists.ebxml.org » Subject: TP teleconference minutes - Feb. 28, 2001 » » » Here are Tony Weida's minutes of the Feb. 28 conference call, with a few » minor additions by me. » » Regards, » Marty » » » Attendees: » » Jamie Clark » Dale Moberg » Becky Reed » Marty Sachs » Tony Weida » » » Becky is working on the new FTP definition to be finalized by » Friday night. » » Dale noted that the Security team has a teleconference going on » at the same » time as our call. » » Marty reminded us of concerns he has about send capabilities (for details » of » this and other items, see his Feb. 26 listserv posting on "CPA-CPP ver. » 0.92 » distributed today"). First, send properties are tied to specific receive » protocols. According to Marty, Chris thought that was okay. Also, » SendingProtocol is a child of Transport. Dale responded that he put it » there to aid CPA negotiation based on CPPs. We decided to leave the send » capabilities as is. » » Dale agreed with Marty that the cardinality for SendingProtocol » in a CPA is » exactly one. » » Tony accepted an action item to contact Chris and settle with him on the » mechanism for validating references to process specifications. » One specific » issue is whether there should be separate digests of the » Process-Specification » Documents or whether they should be included within the overall signature » of the CPP or CPA. » » Marty raise the question of whether a Packaging element is needed under » Override elements and reported that Chris thought it unnecessary, that » overrides should have packaging requirements in common with their » ServiceBinding. » » Marty pointed out that the DTD specifies the cardinality of the Packaging » element as one or more, but the text of our spec says exactly one. » Conclusion: TBD. » » Marty asked about the cardinality of the triplet of child elements under » Packaging. Action item: Marty will discuss this with Dale. » » Tony questioned whether validation of ProcessSpecification references (via » digests) should be done on an all-or-nothing basis. After some » discussion, » it was agreed for phase one (at least) that if any ProcessSpecification » reference is found to be invalid, the whole CPA is to be considered » invalid. » Depending on the outcome of discussions between Tony and Chris, this » relates » to the ProcessSpecification and/or Signature elements. » » Marty pointed out that if a pair of Parties doing business under multiple » business processes wishes to be able to modify a single » Process-Specification » document without interrupting business under the others, they » should create » a sepaate CPA for that process. It was noted that when a CPA references » multiple Process-Specification Documents, it should be assumed that those » processes are interrelated and invalidating the CPA and all of » the Process- » Specification documents when a problem develops with one of them is the » correct action from a business viewpoint. » » » Marty noted (at » least) two cases where Parties might wish to test wether invalidation has » occurred: » » 1. When constructing a CPA from CPPs, the CPPs and the referenced Process » Specification Documents could be tested to see if anything has changed » since the CPP was constructed. » » 2. Once the CPA has been installed, the Parties might want periodically » to test it and the referenced Process-Specification Documents for » validity. » It was observed that when a CPA and the referenced Process-Specification » documents are installed in a system, the information in them is generally » digested by the installation tool and the original documents are not » actively involved in runtime operations. So the Parties are » doing business » based on the state of the CPA and Process Specification documents » when they » were installed and changes to these documents do not affect ongoing » operations » unless and until they have to be reinstalled. » » It was agreed that our document should discuss when ProcessSpecification » references may be "cached" and when they may be checked for validity. » » Jamie noted that the Specification Schema team is making a couple of key » assumptions regarding collaborations: » » 1. There can be infinite nesting of collaborations » » 2. Multi-party collaborations can always be reduced to sets of binary » collaborations, each with a separate CPA » » Marty agreed that proceeding along the lines of #2 is consistent with the » current state of the art in CPA processing. » » There will be no teleconference next week; our next meeting is scheduled » for » March 14. » » Respectfully submitted, » Tony Weida » » » ****************************************************************** » ******************* » » 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 » ****************************************************************** » ******************* » » » » ------------------------------------------------------------------ » To unsubscribe from this elist send a message with the single word » "unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org »
Powered by
eList eXpress LLC