[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 280 - discussion
+1 to Mark's paragraph below. Mark Ford wrote: >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. > Regards, Alex Yiu Mark Ford wrote: >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]