[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
This is a digitally signed message part
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]