RE: Definition of Choreography

David,

>This is a classic religious argument.  In the same way there are
>religious
>battles over big-endian vs little-endian, strongly-typed vs
>weakly-typed,
>interpreted vs compiled, etc., there will be battles of "condition
>based" vs
>"explicit ordering".

That can be said of any argument that avoids specific test cases,
but for this argument, the invitations for test cases have been
issued already.  There is a ball in someone's court...



>While it is certainly true that condition based
>can
>meet all the ordering requirements, there is an issue around usability.
>For
>example, I think coding up JSPs (explicit ordering) is about twice as
>easy
>as XSLT (mostly condition based).  And I also have a metric that every
>time
>you double the complexity, you lose 90% of the developers.

You're assuming that "easy" means "simple" here, but it doesn't.  JSP
is easier because of habit, not because it's simpler.  The mental skills
for declarative specification are probably lacking some in the workforce.
But I find it ironic that the same platform that brings you JSP also
offers things like "declarative transaction" and "declarative security",
which are what you call condition-based forms of specification.

So, there's at least a tradeoff to consider: simpler but less intuitive
specifications - or - unmanageably complex specifications for a workforce
that can go on with its current set of skills.  (Who wants to go on with
just their *current* set of skills?!?)

Any programmer who's learned SQL has already more than half bridged
the gap you're concerned about, I think (provided they can accomplish
work on databased without using cursors ;-).

Walden Mathews