OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Issue 143 - Proposal For Vote

143 - StaticSwitch Activity

Proposal: Add static switch to BPEL

Rationale: This is a very common programming construct that has proved 
its value over the years. It is particularly useful when needing to 
evaluate enumerated values.
	In XPATH it turns out that it's always possible to compare any two 
values no matter what they are and get a Boolean result. But this may 
not be true for other expressions languages so I put in a general 
requirement that staticSwitch's be statically analyzed to determine if 
the values used can be compared. However one can imagine languages where 
even a static check might not be possible. In theory we could cover that 
case by defining a special 'illegalCaseMatch' fault but I'm not 
convinced we need to do that work now.

12.X Static Switch

<staticSwitch standard-attributes>
     <condition expression-language="URI">expression</condition>
     <case value="xs:string">+

The staticSwitch activity evaluates the expression and then compares the 
returned value to the string values recorded in each case in term. The 
details of how the comparison is carried out is expression language 
specific. If the string value in a case matches then the activity in 
that case is executed and the staticSwitch exits. If no case matches and 
there is an otherwise then the activity in the otherwise is executed and 
the staticSwitch exits. If no case matches and there is no otherwise 
then the static switch exits without taking any action. BPEL processors 
MUST statically analyze BPELs and refuse any that return a value for the 
condition expression that cannot be compared to the values in the case 
statements using the language specified for the general expression.

If the condition language is XPATH 1.0 then in effect each case 
statement contains an expression of the form "expression = xs:string". 
If the resulting value is true then the case matches, otherwise it does 
not. XPATH 1.0 is defined in such that such an expression is always 
legal, if not always useful.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]