Does your proposal extend to elements as well? Specifically, should the
declared type of the element variable be considered as opposed to its actual
content?
I'm not sure if others have interpreted the rules as I have but my reading
is that the Qname of the element content drives the match except in the case
of a single part WSDL message which relies on the declared type.
Regardless of this issue is resolved, I think we should clarify the fault
matching rules to remove an possible ambiguities. For example, what would
happen if I had a schema that used substitutionGroups and threw a fault with
an element within the substitutionGroup? Would the fault matching be driven
by the declared type which was the head of the group or by the actual data
which was one of the allowed substitutions?
-----Original Message-----
From: Dieter Koenig1 [mailto:]
Sent: Monday, May 29, 2006 10:00 AM
To: ; Mark Ford
Cc: Thomas Schulze;
Subject: Re: [wsbpel] Issue - 280 - discussion
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:
