[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa-negot] BPSS for Negotiation, the Start element,and clean semantics for process traversal.
Dale,
See my comments below.
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
*************************************************************************************
Dale Moberg
<dmoberg@cycloneco To: "Cppanegotiation (E-mail)" <ebxml-cppa-negot@lists.oasis-open.org>
mmerce.com> cc:
Subject: [ebxml-cppa-negot] BPSS for Negotiation, the Start element, and clean
08/13/2002 11:31 semantics for process traversal.
AM
Hi Marty,
I have now read, I think, all the messages from BPSSers and us
(really, you and Hima) on the question of the entry
point into the negotiation BP.
I gathered that:
1. While a precondition might be useful to nail down where
to start in nested binary collaborations (each with a Start element),
the boolean valued expression language for
those preconditions is not yet defined, nor scheduled to be defined
so that we could make use of it by December.
MWS: Correct. As far as I can tell, they haven't even started
to think about preconditions.
MWS: My concern is less about where to start the nested collaboration
than about making it crystal clear to a BSI where the outer
collaboration starts. The transition from the outer collaboration
to the nested collaboration is stated in the Transition element, so
I don't see the value of the inner Start element.
2. The minOccurs=0 on Start means that we could omit one of
the Start elements. This solution would leave it to
BPSS to decide how to reconcile reusability (which apparently
favors having a Start element within
each BinaryCollaboration) with clear processing semantics
("stepping through the flow"). We would adopt our less
"reusable" approach until they arrive at their solution.
Is there anything besides reusability lost
by omitting the second Start element (in the counter-offer
phase (the nested BinaryCollaboration) of the negotiation
process? If not, it seems the best solution for us until BPSS
works out some of their more elaborate features.
MWS: Omitting the Start element from the nested
collaboration is the most sensible approach. We should state
a (non-normative) caveat that we assume that a deployment tool
will understand the meaning of omission of the Start element
(i.e. that the nested collaboration can only be validly reached from
the outer collaboration).
MWS: My interpretation of the BPSS specification is that something
is GAINED by omitting the second Start element, namely that a
deployment tool and BSI will understand that an initial
message of the choreography that goes directly directly
to the nested collaboration is an error. I know of nothing lost
except reusability. Someone who is initimately familiar with
BPSS deployment tool and BSI implementation may disagree but
as far as I know, no such person has appeared yet.
MWS: The whole question of reusability bothers me, both here and
in WSDL. I don't understand WHAT is reusable. Is it the XML
description or an economically significant amount of code? The price of
reusablility to me is additional complexity in the specification,
which impedes my understanding of it. It also seems to me that
while the specification could promote reusability, it should not
prevent someone from constraining the design to meet their needs.
Dale
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC