Re: [wsbpel] Issue - 280 - proposal draft for discussion (matchinglogic)

Hi, all,

I agree with Mark's description of current matching logic in BPEL.
Current BPEL matching logic is almost best-match based so far.
Sequential matching is necessarily only when faultType feature is added
in future. It is not a must to use sequential matching for
faultElement. 

Mark Ford wrote: 

  
In your
example, E1 would not be caught
except by the default fault handler.

  
I think the
fault matching strategy should
be best match and not consider the order of the elements within the
<faultHandlers>. Since support is currently limited to messages
and
elements, the best match strategy handles all cases. It’s only if we
look
to supporting faultType that we’ll need to consider order. 

I don't have a super strong opinion whether we should use all-the-way
best-match logic or best-match+sequentail-match fix logic. Though I
would admit that I have a tendency to just use pure best-match logic
for faultElement handling. It will be easier for people to understand. 

When we add faultType matching in future, then we will deal with
sequential match logic in future. 

Are people OK with this direction?

If so, I would modify the proposal to reflect that change. 

Thanks!

Regards,

Alex Yiu

Assaf Arkin wrote:
To understand best match you need to subset the potential
catches, then decide which one takes effect based on proximity. It's
simple to write the algorithm, but it's hard to run it in your head
when you need to understand what the process will do, or what just
happened. It's a burden on the user, and I can see a lot of unintended
consequences.
  

  

Sequential match works like people expect it to. First in line takes
priority.

  

Assaf

  

  
On 7/27/06, Alex Yiu <
> wrote:
  
    

    

Hi Danny and Mark,

    

Yes, in Mark's example, the second catch with E2 would be unreachable.

    

In case of Java Language, a similar situation will trigger a compiler
error. 

    

I was also thinking whether to add similar compile-time check in
sequential match part of BPEL's catch logic, when I was drafting the
proposal. I was one step short of adding such a static analysis check.
That will be one of the options. (See the list of options below)

    

In Java, catch is a pure sequential match, not a best match. Given two
data types, one always tell whether one inherit from another type.
Hence, the compiler error report is more straight forward.

    

In XML Schema data model, date item identification is a bit more
complicated because the element aspect is introduced on top of
simple/complexType aspect. Given an element (element A based Type X)
and a type (Type Y), we cannot always tell that one is more restrictive
than the other. 

    

Given we do not have faultType introduced yet, the above
fail-to-compare situation does not exist (fortunately). Among different
faultElements, it seems to me that we can always tell one is the head
of substitionGroup of other. 

    

There are two possible options:

    
      
Keep the sequential check portion of the proposal and add
static
analysis checking to reject unreachable <catch>

      

      
Change proposal to do best match among different
faultElements.

    
If we pick (2),  when we introduce faultType in <catch> *in
future*, sequential match will be used when best match logic cannot be
used. 

    

Please let me know which one you guys prefer. I will update the
proposal accordingly. 

    

    

    

Thanks!

    

    

    

Regards,

Alex Yiu

    

    

    

Danny van der Rijn wrote:
    

      Given the following SG hierarchy: 

        

E1 

|--E2 

   |--E3 

      |--E4 

        

...and the following fault handlers: 

        

<faultHandlers> 

   <catch faultElement="E1"> ... </catch> 

   <catch faultElement="E2"> ... </catch> 

</faultHandlers> 

        

If the runtime data is E4 then E1 and E2 are both compatible but E1
would be 

selected since it appears first. I would have thought that E2 would
have 

been selected since it is closer in the SG hierarchy to E4. 

      
      

Interesting.  I was about to write that you could just reorder the
clauses to get the behavior that you're describing, but what I realized
is that in the current proposal, the 2nd catch in your example is
unreachable.  Would that be an error? 

      

Mark Ford wrote: 

      I don't like the idea of mandatory schema
validation for the keepSrcElement 

case. I don't recall any other part of the spec where we require
validation 

unless it is explicitly indicated with the <assign>'s validate
attribute or 

the <validate> activity. Section 8.4.3 describes type
compatibility but only 

with respect to assigning to and from message variables. I can see how
the 

keepSrcElement validation could be interpreted as being in the same
spirit 

as the message variable type compatibility checks but if that's the
case 

then would people wonder why we don't enforce any other type
compatibility 

during assigns? 

The proposed changes to the fault matching rules in Section 12.5 look
good. 

My previous concerns regarding the determination of the fault data type
have 

been addressed. 

One thing I found missing was that the matching priority only considers
the 

order of the <catch> elements when there are multiple compatible
matches. I 

was expecting to see some consideration of the SG hierarchy. 

        

For example: 

        

Given the following SG hierarchy: 

        

E1 

|--E2 

   |--E3 

      |--E4 

        

...and the following fault handlers: 

        

<faultHandlers> 

   <catch faultElement="E1"> ... </catch> 

   <catch faultElement="E2"> ... </catch> 

</faultHandlers> 

        

If the runtime data is E4 then E1 and E2 are both compatible but E1
would be 

selected since it appears first. I would have thought that E2 would
have 

been selected since it is closer in the SG hierarchy to E4. 

        

-----Original Message----- 

From: Alex Yiu [mailto:]
Sent: Wednesday, July 26,
2006 3:40 AM 

To: wsbpeltc 

Cc: Alex Yiu; 'Dieter Koenig1'; Thomas Schulze 

Subject: [wsbpel] Issue - 280 - proposal draft for discussion 

        

        

Hi all, 

        

Last week, Dieter, Thomas and I have worked together to provide a new
proposal draft for Issue 280. 

        

Please take a look! 

(Since this draft is sent out to the public less than 12 hrs before the
conf call, I guess voting will be up for in the conf call next week) 

        

        

Thanks! 

        

        

Regards, 

Alex Yiu 

        

        

        

        

--------------------------------------------------------------------- 

To unsubscribe from this mail list, you must leave the OASIS TC that 

generates this mail.  You may a link to this group and all your TCs in
OASIS 

at: 

        https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
         

        

  
      

--------------------------------------------------------------------- 

To unsubscribe from this mail list, you must leave the OASIS TC that 

generates this mail.  You may a link to this group and all your TCs in
OASIS 

at: 

      https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
       

    
    

    

    

  
  

  

  
  

-- 

CTO, Intalio

  http://www.intalio.com