Re: [wsbpel] FW: [wsbpel-uc] RE: Issue 24

[Alex Yiu <alex.yiu@oracle.com>]

Phil,

Before we dig into the details of the schema, I would like to bring up a 
few points / questions:

(1) Who is the editor / author of the existing schema? Is he/she 
included in the list of people already?

(2) There are two approaches we can tackle this schema rewriting:

[A] a 3-way relation: (suggested by Bernd) a common base type, which is 
inherited by both executable-BPEL subtype and abstract-BPEL subtype
[B] a 2-way relation: using abstract type as the base type and 
executable inherit directly or indirectly from the abstract type. The 
inheritance may be done through two steps: one restriction, one 
extension if needed. E.g. tFromAbstract has opaque attribute; 
tFromExeBase inherits from tFromAbstract by restricting the use of 
opaque; tFromExe inherits from tFromExeBase by extending and adding 
query attribute.

Between [A] and [B], we would prefer [B]. We think most of BPEL element 
type should use pattern [B]. Because, it have a clearer relation between 
abstract and executable BPEL elements. For [A], abstract and executable 
BPEL element definition can diverge a lot. The extreme case is the base 
type would not have an empty type definition, and most of the "meat" 
happen in two separate inheritance extension. That is we would not like 
to see.

(3)
The current form BPEL spec does not spell difference of abstract and 
executable clear and explicitly enough. It just has two relatively brief 
extension chapters and pieces of description scattered around the spec.

For example, in the XML Schema, the minOccurs of partnerLinks element 
under Process is zero now. I tend to believe that zero can only make 
sense in abstract BPEL, executable BPEL should have at least one 
partnerLink. There is a similar situation for variables declaration.

All these are guessed by our intuition when we are reading spec. We 
really prefer that all those distinctions are spelled explicitly in 
both: (a) expanded chapters for extensions in the spec (e.g. chapter 14 
and 15, using natural language) and (b) XML Schema listed in the 
Appendix. The more details, the better. The more earlier, the better.

(4)
Once we decide the approach, we need to find a way to divide actual 
works among us.


Thanks!



Regards,
Alex Yiu



Rossomando, Philip wrote:

>Guys:
>
>At the last TC I, Paco, Tony, Alex and Ron were charged
>With pushing Issue 24 to completion. I would like to know
>If any action has been taken and if not, let's get something
>Started. Danny raised a good point let's get it resolved.
>
>Phil
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>  
>