[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Minutes of today's conference call.
My rejoinders embedded below. ************************************************************************************* 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 ************************************************************************************* "Burdett, David" <david.burdett@commerceone.com> on 10/05/2000 01:42:18 PM To: Martin W Sachs/Watson/IBM@IBMUS, "Moberg, Dale" <Dale_Moberg@stercomm.com> cc: ebxml-tp@lists.ebxml.org Subject: RE: Minutes of today's conference call. Marty What you describe involves taking a PA and generalizing it. I don't think this works as a PA probably contains a subset of everything that a party can do. MWS: I interpreted the original suggestion as to extract a PP (or both PPs) which contain only the subset functions. My take on the process is as follows: 1. Take two PPs - one for each party 2. Identify where the two PPs "align" i.e. technology, business process, etc are common to both 3. Create an initial PA that consists of the two PPs that are common MWS: Up to this point we are composing a PA from two PPs, perhaps with an autonegotiation process involved. 4. Identify where there are more than one alternative and either: MWS: The idea here, I gather, is to preserve the unused options and alternatives within the PA but in some kind of "switched off state". I had earlier suggested simply commenting them out. a) allow them all and specify rules to be applied at run time to determine which one is to be used, or MWS: The rules could be embedded in the composed PA. However, I would prefer that the rules be applied once, when the PA is installed at each partner's system rather than to have to execute them for every message or every conversation. Of course for more dynamic e-commerce, where the PA may only be used for a single interaction, the two alternatives are really the same. b) through some sort of negotiation, identify the specific set of technologies, business processes, etc to be used MWS: (b) is the negotation process that may be involved in composing the PA. The difference here is that those functions discarded in the negotation process would be preserved within the PA per (4a). The interesting one is how do you actually do "4a" ... MWS: The result of all this is that the resulting PA could be decomposed into the original PPs rather than into PPs which only reflect the choices made when the PA was composed. David -----Original Message----- From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com] Sent: Thursday, October 05, 2000 7:26 AM To: Moberg, Dale Cc: ebxml-tp@lists.ebxml.org Subject: RE: Minutes of today's conference call. I completely agree with Dale. I believe that the words I am putting into the update of the Requirements document will express his view. I'm sure someone will comment if I miss the mark here. The idea is not to extract the original PPs from the PA. That would be impossible because in creating a PA from two PPs information related to the capabilities not used in this PA are lost unless they are preserved in comment tags, which I don't think we want to do. The idea that I understood in the suggestion was to take an existing PA (perhaps manually created without PPs) and extract from it PPs which reflect only the information in that PA. Such a PP could be used in creating essentially the same PA with a different partner. In our IBM Research project, we do essentially the same thing by feeding an existing PA into our authoring tool to use as a model for a new one. 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 **************************************************************************** ********* "Moberg, Dale" <Dale_Moberg@stercomm.com> on 10/05/2000 09:17:23 AM To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-tp@lists.ebxml.org cc: Subject: RE: Minutes of today's conference call. >Look at #4 (pg 3). > Should be possible to automatically extract a >PA from a PP. [ issue here was extracting PPs from PA-- hope I didn't transpose these when speaking] >Dale: not sure this will be a good thing. What if just one >PA of a PP is agreed to? Requirement to retrieve original PP is overly >strong. What if it's just to extract PA from a PP? OK. I would like to clarify what I was concerned with on the PP extraction from a PA. Because a PA may be formed from subsets of the two underlying PPs, (or because I think this should be possible), it is overly restrictive to require that the original PPs be extractable from a PA. What is OK, I think, is that some PP or other be extractable from a PA. I reserve complete agreement until I see the procedure for doing this. I think the roles of the Ps in the PA will be clear so we could tell which part of a BP/CP the Ps advertise in their PPs. Marty could probably clarify this for us for the current documents we are initially considering. I always think of the PPs as really capability inventories, and the actual agreement is really on what real delivery channels will suffice to "deploy" the BP. Granted that may be a bit simplistic, but it helps me orient myself. The situation will be common that one Party (a big hub kind of node) will have a lot of capabilities (in comms, security, BPs, and so on) while SME nodes will have quite restricted capabilities and interests (can I get that in a spreadsheet or fax?...) If things emerge so that some capabilities are outsourced, then some d. channels will really be intermediary proxy capabilities. I think we should prepare for this sort of complexity in phase 1, with the details by phase 2.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC