RE: [ebxml-bp] Considerations for v20

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

the sidebar I would like bring about the following suggestions for ebBP
2 considerations.

* Focus on the "Business" side of the protocol and not so much on
technical features such a XPath.

Xpath is a technical choice to be used in a condition language (shell).
Presumably the real semantics is found in the expressions referenced. Or
am I missing your point here? Perhaps you are calling for more
illustrations of usage of condition languages?

* Focus on finding support for "instrument of offer" rather than better
XML support.

Anders, I am not familiar with the implications of the quoted phrase. Is
this intended to replace the idea of "Request" somehow? I hope that
lower level concepts like MEP can be properly separated from higher
business level categorizations of processes with varying intent,
presuppositions, and effects. Illocutionary and perlocutionary aspects
of utterances still can ride on acoustic waves, after all. I am all for
keeping layers clear, but in some ways, BPSS is relating how the higher
semantics cling to a (slightly abstracted) collaboration protocol layer
in carrying out their tasks. The focus must straddle both IMO.

* Recognise that the target users are SME companies so adding technical
complexities that makes the protocol difficult to "understand" for
business users and expensive to implement should be avoided.

Will BPSS be something a SME ever sees? I doubt it. I hope we expect to
rely on GUI abstractions to protect the SME user from either the UMM/UML
or XML goo underneath. But simple is good as long as it is not overly
simple :-) (apologies to Einstein) 

* Avoid adding or hardcode dependencies to new specifications unless
there are 
real business values identified.

Always a good idea.