[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 2 - A modest proposal
Ivana, By "another abstraction" I meant that the <scopeDeclarations> element can occur in a <scope> or a <scopeDeclaration>. For example: <scope> <scopeDeclarations> <scopeDeclaration typeName="fooType"> <scopeDeclarations> <scopeDeclaration typeName="barType"> <empty/> </scopeDeclaration> </scopeDeclarations> <SCOPE name="bar" type="barType" /> </scopeDeclaration> </scopeDeclarations> <SCOPE name="foo" type="fooType" /> </scope> yields: <scope> <scope name="foo"> <scope name="bar"> <empty/> </scope> </scope> </scope> -maciej On Tue, 2004-09-28 at 12:23, Trickovic, Ivana wrote: > Maciej, > > I find the proposal interesting (at least for locally defined reusable pieces of BPEL code). Would you give an example of an "another abstraction" where the scope abstractions can be declared? > > Regards, > > Ivana > > > > -----Original Message----- > > From: Maciej Szefler [mailto:mbs@fivesight.com] > > Sent: Samstag, 25. September 2004 21:51 > > To: Trickovic, Ivana > > Cc: wsbpel@lists.oasis-open.org > > Subject: [wsbpel] Issue 2 - A modest proposal > > > > > > Ivana, > > > > Keeping in mind the understandable desire by certain members > > of the committee to make these things macros and your desire > > to address this issue, what do you think about the following approach: > > > > We create the notion of a "parameterized scope" an "abstraction" of a > > scope. These scope abstractions must be declared (in a scope, or in > > another abstraction), using a syntax nearly identical to that > > of scopes: > > <scope> > > <variables>? > > <correlationSets>? > > <partnerLinks>? > > <faultHandlers>? > > <compensationHandlers>? > > > > <scopeDeclerations> > > <scopeDeclaration typeName="typeName"> > > <parameters> > > <param name="paramName" {message,element,}type="" />* > > </parameters> > > <faultHandlers?> > > <compensationHandlers?> > > <variables?> > > <correlationSets?> > > <partnerLinks?> > > <any-activity> > > </scopeDeclaration> > > </scopeDeclerations> > > ... > > </scope> > > > > To use a scope abstraction we have a new "concretion" activity: > > <SCOPE name="scopeName" type="typeName"> > > <arg paramName="paramname" replacement="visibleVarName" />* > > </SCOPE> > > > > So the construction: > > <scope> > > <scope name="foo"> > > <empty/> > > </scope> > > </scope> > > > > is equivalent to; > > > > <scope> > > <scopeDeclerations> > > <scopeDecleration typeName="fooType"> > > <empty/> > > </scopeDecleration> > > </scopeDeclerations> > > > > <SCOPE name="foo" type="fooType" /> > > </scope> > > > > > > In the other direction, the concretion <SCOPE name="foo" > > type="bar" can > > be defined simply in terms of an XML re-write rule: it is > > equivalent to > > writing <scope name="foo"> with the body found in scopeDecleration of > > typeName="bar" subject to renaming of names found in the <parameters> > > block to the names specified in the <arg> elements. In order to keep > > this a pure "macro" we have to disallow recursion, and we > > must disallow > > free variable or link names in the scope declarations (i.e. parameters > > are the only way to pass data around). > > > > To do functions: > > > > <scope> > > <scopeDecls> > > <scopeDecl typeName="multiply"> > > <parameters> > > <vararg name="x" ../> > > <vararg name="y" ../> > > <vararg name="product" ../> > > </parametrs> > > <assign> > > <to variable="product" /> > > <from>$x * $y</from> > > </assign> > > </scopeDecl> > > </scopeDecls> > > > > <scope> > > <variables> > > <variable name="a1"/> > > <variable name="a2"/> > > <variable name="a3"/> > > <variable name="a4"/> > > <variable name="a5"/> > > <variable name="a6"/> > > </variables> > > <sequence> > > <SCOPE name="s1" type="multiply"> > > <vararg paramName="x" varName="a1" /> > > <vararg paramName="y" varName="a2" /> > > <vararg paramName="product" varName="a3" /> > > </SCOPE> > > <SCOPE name="s2" type="multiply"> > > <vararg paramName="x" varName="a2" /> > > <vararg paramName="y" varName="a3" /> > > <vararg paramName="product" varName="a4" /> > > </SCOPE> > > <SCOPE name="s3" type="multiply"> > > <vararg paramName="x" varName="a4" /> > > <vararg paramName="y" varName="a5" /> > > <vararg paramName="product" varName="a6" /> > > </SCOPE> > > > > </sequence> > > </scope> > > </scope> > > > > > > The appeal of this approach is that it gives you parameterization, and > > can be done completely on the XML re-writing level (simple XSLT can do > > it) without introducing any new "native" BPEL constructs. > > > > If you want to get even fancier, you can also have link parameters. > > > > -maciej > > > > 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. > >
This is a digitally signed message part
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]