[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 280 - discussion
|
The part of the rules that I'm questioning has to do with rule #2 and #5
which cover the single element part WSDL message. Do you read this to say that
the QName for the element comes from the actual element data or the declaration
of the <part element="qname"/> in the WSDL? There are cases where the
QNames could be different. It would be possible to construct a WSDL message
variable and populate it with an element for use with a <throw> that
differed from the element QName in the part description. Perhaps the element
used was part of a substitutionGroup or perhaps it was simply user error. In
either case, I'd like to clarify which QName to use for the element when
matching.
Here's rule #2 with my emphasis:
2.
Otherwise if
the fault data is a WSDL message type where the message contains a
single part defined by an element and there exists a
<catch> construct with a matching faultName value that has a faultVariable whose associated faultElement�s QName matches the QName of the element
used to define the part then the fault is passed to the identified
<catch> construct with the faultVariable initialized to the value in the single part�s
element. It seems to me that we're driving this match based on the <part
element="qname"/> from the WSDL and not from the element data. If this is the
intent, then it feels a little inconsistent since in the other cases we're
basing the match on the contents of the data as opposed to some declaration of
its type. If this is not the intent, then perhaps this section could do
with a slight rewording to make it more clear?
From: Alex Yiu [mailto:alex.yiu@oracle.com] Sent: Monday, May 29, 2006 9:35 PM To: Mark Ford Cc: 'Dieter Koenig1'; 'Thomas Schulze'; wsbpel@lists.oasis-open.org; Alex Yiu Subject: Re: [wsbpel] Issue - 280 - discussion Hi Mark, Hope you had a good long weekend ... :-) I would like to address your question about "ambiguities" of the last part of email. The current rule is clear to me that we are doing an exact QName match. That is, substitutionGroup is not considered in the <catch> matching logic. Further elaboration: <catch faultElement="foo:bar"> will catch only faults that is of either element whose exact QName is "foo:bar" or message type of single part of element whose exact QName is "foo:bar". And, it will NOT catch a fault of element "foo:bar2" which is a part of substitutionGroup of "foo:bar". Our current <catch> rule does not touch any XML schema typing issue at all. If in future we are ready to handle XML schema typing in our <cach> matching rules, we can for sure consider adding support for substitutionGroup at <catch> with a switch (that is a 20% usecase). Back to commenting a bit more on Dieter's proposal: if we had introduced "faultType", that I would consider it is a 50%~80% of people would expect type-matching, instead of QName matching. That was also what I mentioned to Yaron back in Fall 2005. Yaron decided not to deal with the type matching problem by not introducing the "faultType" attribute in NY F2F (Dec 2005). Thanks! Regards, Alex Yiu Mark Ford wrote: 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:dieterkoenig@de.ibm.com] Sent: Monday, May 29, 2006 10:00 AM To: alex.yiu@oracle.com; Mark Ford Cc: Thomas Schulze; wsbpel@lists.oasis-open.org 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: dieterkoenig@de.ibm.com 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 <mark.ford@active-endpoints.com> cc Thomas Schulze/Germany/IBM@IBMDE, wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com> 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: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]