OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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.

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
4. Identify where there are more than one alternative and either:
  a) allow them all and specify rules to be applied at run time to determine
which one is to be used, or
  b) through some sort of negotiation, identify the specific set of
technologies, business processes, etc to be used

The interesting one is how do you actually do "4a" ...

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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC