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.



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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC