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