W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2004

RE: Coordinated Choreographies Proposal 3 - Multiple Finalizers

From: Haugen Robert <Robert.Haugen@choreology.com>
Date: Sun, 7 Nov 2004 17:44:22 -0000
Message-ID: <221369570DEDF346AE42821041345E8951BC6B@imap.choreology.com>
To: "Gary Brown" <gary@enigmatec.net>, <public-ws-chor@w3.org>
Response below.

Gary Brown wrote:
> Regarding the use of the 'name' attribute on the finalizer - 
> just wondering 
> whether it would be more appropriate to have an additional 
> attribute (which 
> I seem to remember seeing in a previous version of this 
> proposal as 'case'), 
> which would have a well defined list of values, as opposed to being 
> completely free-format.

You are correct, the initial proposal had an additional 'case'
But we did not prescribe a well-defined list of values.
We think in many cases, including those of child choreographies extended
from parents, or mergers of business and technical protocols, some of
those values will want to be application-specific - as in the TWIST
examples, where you have "drawDown" and "replenish", or "priceAccepted"
and "notDone".

We thought about it earlier because 'case' seemed redundant, but the
tipping point for eliminating 'case' and going with 'name' was to make
the "extends" syntax consistent.  Everything else was by-name.  Why not
> Is there a stable list of finalizer types that you have in 
> mind, or do you 
> need it to be completely extensible? e.g. confirm, cancel, close, etc.

We do think that the world should converge on one and only set of
business transaction signals (e.g. confirm and cancel), but the world
(e.g. WS-CAF, WS-TX) continues to disagree.  
For example, when I did a comparison of BTP, WS-CAF and WS-TX in April,
I found 8 different names for the equivalent of finalizers - or 6
different sets of names, if you want to consider matched sets.

But we're also talking about business protocols, or industry business
process standards, which are much more various, and much less likely to
converge. We think CDL could become a good choice for expressing those.
And the "extends" proposal allows merging business and technical
protocols, which we think will help even more.

So in short, yes, it needs to be completely extensible.

Choreology Anti virus scan completed
Received on Sunday, 7 November 2004 17:45:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:06 UTC