Prasad,
Thanks for catching this paragraph as well. Particular the sentence:
"This
one-to-one relationship is necessary in order to guarantee
proper targeting for
fault catching."
I think that sentence also is having similar problem of "To ensure
uniquenes".
I would describe the problem as using some "normative and formal
looking words" in a non-normative, informal, un-enforcable fashion.
If those wording normative, formal and enforcable, the spec would need
to clearly define what "uniqueness" means. That is what is the scope
of uniqueness here? WSDL only? applied to <throw> as well?
Similar, the spec would need to define what "one-to-one" relationship
means: from concept X and to concept Y. X may be the fault name in
<catch>, but Y is totally undefined: fault name defined in WSDL?
how about fault name used by <throw>.
If you try to apply XSD's key and keyRef and relational DB
unique/primary key and foreign key relationship, then you would get
what I mean. :-)
And, repeating myself here: after clarification of these sentence, the
current form of <catch> is simple and unified enough for majority
of BPEL users.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
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.
Regards,
Prasad
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:
>
>http://www.w3.org/TR/wsdl20/#InterfaceOperation_details
>
>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.
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).
Assaf
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.
Prasad
|