[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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