OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 280 - proposal draft for discussion (matching logic)


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.

 

 


From: Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Friday, July 28, 2006 12:17 AM
To: Alex Yiu
Cc: Mark Ford; wsbpeltc; Dieter Koenig1; Thomas Schulze
Subject: Re: [wsbpel] Issue - 280 - proposal draft for discussion (matching logic)

 

I agree that it's reachable in that case.  But it's bizarre in that given the same hierarchy, but the following handlers:

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

then E1, E2, and E4 are caught by the first, and E3 is caught by the second.  That's strange.

Alex Yiu wrote:


Hi all,

Hmm ... actually Mark is right about <catch> with E2 is reachable.

Mark wrote:

It's reachable in the current proposal. The first priority is the identical QName match.

Sorry for the confusion caused by my email sent out 45 mins ago. I did not sleep well last nite. :-)

Given that the priority goes to identical QName match in the current proposal, "unreachable" analysis for faultElement does not apply.

Then, back to Mark's original question: do we want sequential match or best match for faultElement?

I am open to both version.


Thanks!


Regards,
Alex Yiu



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:

  1. Keep the sequential check portion of the proposal and add static analysis checking to reject unreachable <catch>
  2. 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:alex.yiu@oracle.com] 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

 

 

--------------------------------------------------------------------- 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]