where is the dividing line?

["Martin Chapman" <martin.chapman@oracle.com>]

I've been listening with great interest to the discussions on abstract BPEL as contracts, abstract BPEL as templates, and 
abstract BPEL as an intermediate language, and I agree each use case is valid. What I am having trouble with is how we can define a single language to meet all these goals; where is the single dividing line between abstract and executable BPEL?

When a company exposes a definition to another company surely it is up to the company to decide
 how much detail it wants to expose.
If a company chooses to expose an executable BPEL definition who are we to stop them?
In fact there is no way of stopping them.
Internally, a company may want to expose more detail between analyst and programmer then they would to external parties, and different companies will have different rules about what can be exposed and where.
Some people may want to make extensive use of <opaque> to inform others that something internal will happen, others may stick to plain old extensibility.

My point is that all these use cases are valid, yet they appear to have different exclusion requirements on the language, and that different companies may have different polices as to what gets exposed (or not). Is it really possible to define a single syntax under the abstract BPEL umbrella, which all vendors support and which precisely matches a variety of customer usage policies. Sounds more than a single language to me; it sound like a family of syntaxes. Wouldn’t it be better just to define a single language (BPEL) and let tool vendors support customisation that allows each *Customer*  to  decide what features are in and out?

Look forward to your feedback,
   Martin.



_________________________________________________________________
Martin Chapman                                 
Consulting Member of Technical Staff           
Oracle                                        
P: +353 87 687 6654                           
e: martin.chapman@oracle.com