[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 280 - discussion
My concern is that the existing rules for determining the type of fault data are ambiguous. Alex's reading is that the rules are based on the fault data. My reading is that rule #2 and #5 involve the declaration of message part. Thomas' reading is that it is based on the declared type of the variable or message part. Forgive me if I misread your interpretations but at the very least there is more than one interpretation so it's something that needs to be addressed. If we change the existing text to make it explicit that the data type is determined by the declaration of the fault variable and/or message part (for rule #2 and #5) then it seems that we could allow support for throwing and catching type based variables without any problems. One thing that we would lose with this approach is the ability to throw a variable with some base type and have it match against some derived type based on the actual Qname of the root element. I'm not convinced that this is a bad thing. I think that it's possible to close this issue without bringing up any new issues like inheritance or keepSrcElement. Catching faults by an identical match of their declared Qname seems like a reasonable first pass. Perhaps a future version of the spec could enhance this to include support for matching based on inheritance but this doesn't seem incompatible with adopting a strict declared Qname approach at this point. -----Original Message----- From: Thomas Schulze [mailto:ThomasSchulze@de.ibm.com] Sent: Saturday, June 03, 2006 12:30 PM To: Alex Yiu Cc: Alex Yiu; Dieter Koenig1; Mark Ford; wsbpel@lists.oasis-open.org 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]