RE: [wsbpel] Issue - 280 - discussion

["Mark Ford" <mark.ford@active-endpoints.com>]

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>