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] Re: Issue 304 - discussion - clarification on whetherthe QName of a fault needs to be unique across all portTypes and operations

I still do not ge the relation of that to what we are discussing. The uniqueness of faultName QName comes from BPEL. E.g. see section 12.5:

"Data thrown with a fault can be a WSDL message type or a XML Schema element. Each <catch>, which specifies a QName as its faultName attribute value, can only catch a fault matching that particular QName. This one-to-one relationship is necessary in order to guarantee proper targeting for fault catching. "

If the faultName QName defined in WS-BPEL does not have a 1-1 match with a fault in WSDL 1.1 (as the fault names are not unique per the WSDL component model and fault name is defined to be an NCName not a QName),  then it is in violation of the WS-BPEL spec as written now. Only way that can happen is if we constrain WSDL fault naming, which has the draw backs already mentioned.

If we do not want WS-BPEL fault QNames to be unique, lets us state that and clear-up the confusion, that way we will not violate WSDL 1.1 model. That is what I was suggesting by saying the alternative is not to require the WS-BPEL faultNames to be unique QNames.

My preference however is to stream-line this so that same fault names (for the same faults) are usable with multiple interfaces and operations, as that is highly desirable.


Assaf Arkin wrote:
On 7/24/06, Prasad Yendluri <pyendluri@webmethods.com> wrote:

>Assaf Arkin wrote:
>On the other hand, WSDL 2.0 does exactly that. Each operation has a name property of type QName, and the spec clearly indicates two operations may >share the same QName:
>So it's a matter of which precedent you prefer to judge by. I don't see a problem with the fault QName, I think it keeps the catch as simple as it possibly can be.

The WSDL 2.0 spec says,

a) "For each Interface Operation component in the { interface operations} property of an Interface component, the { name} property MUST be unique. †"

This talks about unique names withing the same interface, the case I'm talking about is having two operations with the same name in two different (and unrelated) interfaces.


c) Where "Two component instances of the same type are considered equivalent if, for each property of the first component, there is a corresponding property with an equivalent value on the second component, and vice versa."

In case of two different operations with the same QName coming from two different interfaces, although they have the exact same QName, they are not equivalent since they differ by at least one property: their parents.

So, WSDL 2.0 first is defining the operation name to be a QName ( {name} REQUIRED. An xs:QName.) and says when the same QName is used on two different operations, they MUST be equivalent.

Only if they belong to the same interface, directly or indirectly (through inheritence).


This is very different from WSDL 1.1 fault name where the fault name is first not defined to be a QName and it is defined to be unique only within the context of a specific operation and in a specific portType.

This is comparing apples and oranges. One does not follow from the other.


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