[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsbpel] Issue - 280 - discussion
Resending this note with hopefully better formatted examples... Best regards/Mit freundlichen Grüßen, Thomas Schulze ----- Forwarded by Thomas Schulze/Germany/IBM on 03.06.2006 18:28 ----- Thomas Schulze/Germany/I BM To Alex Yiu <alex.yiu@oracle.com> 03.06.2006 17:22 cc Alex Yiu <alex.yiu@oracle.com>, Dieter Koenig1/Germany/IBM@IBMDE, Mark Ford <mark.ford@active-endpoints.com>, wsbpel@lists.oasis-open.org Subject Re: [wsbpel] Issue - 280 - discussion(Document link: Thomas Schulze) Hi Alex, this keepSrcElementName attribute is really very odd. What's the result of the following assign if both variables are element-typed and the element QNames are not equal? <assign validate="yes"> <copy keepSrcElementName="yes"> <from variable="var1"/> <to variable="var2"/> </copy> </assign> Doesn't this ALWAYS result in the bpel:invalidVariables fault? For a second example how odd this attribute is, assume there's no validate="yes" on that assign, but in another activity after that assign there's a XPath query/expression into var2. I assume the XPath query/expression is written by the modeller upon the assumption that the content of the variable is the one as declared. So the XPath query/expression will result in a fault. Additionally, this fact makes it impossible for a static analysis tool to validate any XPath queries/expressions in a BPEL 2.0 process (Btw. that would be one of the cases where BPEL 2.0 is not backwards-compatible with BPEL 1.1 where such checks were possible ;-) IMO, this attribute is the only reason why we currently need a catch logic based on the concrete fault data type and not on the declared data type of the thrown variable, right? I would prefer to change the catch logic to QName matching based on the declared data type of the thrown variable and remove the attribute keepSrcElementName from <copy>. In addition, the catch logic for elements then would be consistent with the logic for rule 2 and 5. But I think such changes should be subject of another issue. So when catching types, the logic should be as equal as possible to that what we already have when catching elements. This still means, the existing catch rules 1 and 4 would be sufficient, as outlined by Dieter. No additional rule nor a change at the existing rules would be needed (and too no clarification, I think). For the following example, you've send it some notes ago, this would mean that the second <catch> gets it. Example #2 --------------------------- <scope> ... <catch faultType="foo:addressType"> ... </catch> <catch faultType="foo:usAddressType"> ... </catch> ... <variable name="addrVar" type="foo:addressType" /> <variable name="usAddrVar" type="foo:usAddressType" /> ... <assign> <copy> <from variable="usAddrVar"/> <to variable="addrVar" /> </copy> </assign> ... <throw name="throw1" faultVariable="addrVar" /> </scope> --------------------------- Best regards/Mit freundlichen Grüßen, Thomas Schulze Alex Yiu <alex.yiu@oracle. com> To Thomas Schulze/Germany/IBM@IBMDE 30.05.2006 23:37 cc Dieter Koenig1/Germany/IBM@IBMDE, Mark Ford <mark.ford@active-endpoints.com>, wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com> Subject Re: [wsbpel] Issue - 280 - discussion Hi Thomas, [a] Regardless whether we want to support faultType in BPEL 2.0, you mentioned another good corner case that we need to clarify - i.e. when element variable contains an element data which is NOT identical to the element QName used in variable declaration. (similar to Mark's case) E.g.: --------------------- <scope>