Re: [wsbpel] Issue - 107 - Proposal for Vote

["Yaron Y. Goland" <ygoland@bea.com>]

+1

Re-written proposal:

An activity called 'opaque' shall be introduced for the exclusive use of 
abstract processes. The opaque activity's semantics are that it is a 
place holder for a single activity. The author of an executable 
complement of an abstract process has sole discretion as to what 
activity to replace an opaque activity with.

An opaque activity is a BPEL activity and therefore has the same 
standard elements and attributes that all BPEL activities have.

The reserved value "##BPELopaque" shall be made available for use as the 
value of any BPEL attributes in a BPEL abstract process that accept a 
QNAME or NCNAME. The reserved value's semantics are that it is a place 
holder for some other QNAME/NCNAME. The author of an executable 
complement of an abstract process has sole discretion as to what 
QNAME/NCNAME to replace the reserved value with.



Alex Yiu wrote:

> 
> 
> Hi all,
> 
> 
> I guess you guys would not be surprised that I actually some preliminary
> preferred answers to my own questions. :-)
> 
> Please see inline ....
> 
> 
> Alex Yiu wrote:
> 
>  >
>  > Hi Yaron,
>  >
>  > You move to the proposal stage of Issue 107 faster than I expect. :-)
>  > I am for the spirit of Issue 107 in general.
>  > However, there may be some technical details which we may still need
>  > to nail down.
>  >
>  > (a)
>  > One detail is about the syntactic issue of QNAME of "bpel:opaque".
>  > (I am thinking out loud below ...)
>  > Some attributes used in BPEL now are QNAME or NCNAME.
>  > In XML Schema or WSDL 2.0, we have special value string as "##any" or
>  > "#any" for some of their special attribute.
>  > We may want to use "##opaque" or "#opaque" instead (?)
>  >
> 
> Let's try to use "##opaque".
> 
>  > (b)
>  > Other questions are: does <opaque> have a name attribute itself?
>  >
> 
> Definitely, we should have a name attribute. We may want to add a
> required / optional "<documentation>" sub element also.
> 
>  > (c)
>  > Does it have all standard elements and attributes similar to other
>  > actvities?
>  > (e.g. <source> <target> suppressJoinFailure attributes
>  >
> 
> Yes, we want to have those standard elements and attributes.
> Then, the <opaque> element will be more expressive. That is, some
> activities should happen here in the <opaque> places. Details are not
> known in the abstract BPEL drafting. However, the execution of
> activities for the place holder will have given cause and effects in
> terms of <source> and <target>.
> 
> That is one of the reasons why we should have ONE activity per <opaque>
> place holder (as stated in my previous email). And, we use <sequence>,
> <flow> and <scope> for many activities, while <empty> for zero activity.
> 
>  > (d)
>  > <opaque> can be used as a place holder for a single activity.
>  > How about some activities container? <onAlarm>,  <case>, <otherwise>?
>  > and different kinds of Handlers?
>  >
>  >
> 
> Let's be more conversative for now. We may not want to bite too much in
> terms of usage of <opaque> than we can swallow. I would tend to think we
> should NOT try to use replace the activities container listed above for
> BPEL 1.1 cycle.
> 
> 
> I hope all these suggestions make senses to you guys!!!
> 
> 
> Thanks!
> 
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> 
> 
>  >
>  > Sorry for raising questions in this stage. However, I think we need to
>  > answer some of these questions before the voting.  :-)
>  >
>  >
>  >
>  >
>  > Regards,
>  > Alex Yiu
>  >
>  >
>  >
>  > Yaron Y. Goland wrote:
>  >
>  >> An activity called 'opaque' shall be introduced for the exclusive
>  >> use of abstract processes. The opaque activity's semantics are that it
>  >> is a place holder for a single activity. The author of an executable
>  >> complement of an abstract process has sole discretion as to what
>  >> activity to replace an opaque activity with.
>  >>
>  >> A QNAME bpel:opaque where the bpel namespace shall be the URI
>  >> used by the bpel spec for its own namespace shall be made available for
>  >> use as the value of any BPEL attributes in a BPEL abstract process that
>  >> accept a QNAME. The reserved QNAME's semantics are that it is a place
>  >> holder for some other QNAME. The author of an executable complement
>  >> of an abstract process has sole discretion as to what QNAME to
>  >> replace a reserved QNAME with.
>  >>
>  >>
>  >>
>  >> 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. 
> 
>  >>
>  >>
>  >
>  >
> 
>