Hi Alex and Mark, rules 1 and 4 should take care of both element and type
by means of strict QName matching.
In other words,
- when a variable is defined with a type ns:t then it can be caught using
a faultType that specifies the same QName ns:t
- when a variable is defined with an element ns:e then it can be caught
using a faultElement that specifies the same QName ns:e
This clarification would need to be added to the two rules, and the
faultType attribute be added to catch.
Kind Regards
DK
Dieter König Mail: IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
Alex Yiu
<alex.yiu@oracle.
com> To
Mark Ford
24.05.2006 19:47 <>
cc
Thomas Schulze/Germany/IBM@IBMDE,
, Alex
Yiu <>
Subject
Re: [wsbpel] Issue - 280 -
discussion
Hi,
[ Changing the subject line ... such the issue list can "correlate" this
email thread ;-) ]
Currently, there is a set of rules stated in section "12.5 Fault
Handlers" to determine which <catch> will be used during fault handling.
(under "in the case of faults thrown with associated date ...")
As Mark stated, if we want to support XSD-type (both simple and complex
type) in the <catch> clause, we need to modify that set of rules
significantly. There are 6 rules involved in that set. They are just
using element's QName matching and message type's QName matching there.
The passed resolution intentionally avoid any type inheritance-based
checking there.
If we allow simple-type or complex-type based <catch> clause, it would
be odd to some users, if we don't do any type inheritance-based checking
(similar to Java catch). If we do inheritance-based checking (e.g. a
"foo:AddressType" based <catch> can handle a "foo:USAddressType" fault),
we would wander in the territory of "best-match" schema type semantics,
which I am not sure any other spec has done that before.
If we don't do inheritance-based checking, it may not be that simple
either to resolve all the most appropriate <catch> either. e.g. which
one will be matched?
<catch faultType="foo:AddressType">
vs <catch faultElement="foo:AddressElem">
(where "foo:AddressElem" is based on "foo:AddressType")
vs <catch faultMessageType="foo:AddressMsgType">
(where "foo:AddressMsgType" has a single part based on "foo:AddressType")
I am quite sure if we spend enough time, there will be a matching
algorithm developed. But, at the same time, the 80-20 rules applies
here. That is, we may need to double the size of rules (from 6 to 12)
for a 20% usecase? Complexity kills usability.
Last, it may be too late for this cycle of spec to add such a new
feature to <catch>.
I hope my train of thoughts sound reasonable to you guys.
Thanks!
Regards,
Alex Yiu
Mark Ford wrote:
