[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 107 - Proposal for Vote
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. >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]