[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsbpel] Issue - 280 - Proposal to Vote
Alex, the formal point about bugs and features is up to vote when an issue
is opened, so I am not responding to that.
Two questions:
1. Matching the *declared* type
Consider a variable "blue" declared with an element "blueElement", and a
fault handler with a faultVariable declared with faultElement
"blueElement". An assignment (with validate="no" and
keepSrcElementName="yes") puts an invalid value "redElement" to the
variable "blue". Finally, a throw activity throws a fault with the variable
"blue".
If there is no strict matching based the declared QName then the fault
handler defined with faultElement "blueElement" does NOT catch this fault.
The result is an indeterministic fault handling model based on invalid
variable values (another dynamic variation of GOTO), and definitely not a
behavior encouraged for business processes.
Q1: can you provide a usage scenario (hopefully different from the one
above) where strict matching based the declared QName is not sufficient?
2. Strict QName matching of *faultType*
Consider two elements, E1 defined of type T1, E2 defined of type T2, where
T2 is a restriction of T1.
When a variable declared with E2 if thrown then a fault handler with a
faultVariable declared with element E1 would never catch it (strict QName
matching, ok!).
When a variable declared with T2 if thrown then a fault handler with a
faultVariable declared with type T1 would ALSO never catch it (strict QName
matching).
Q2: can you explain why strict QName matching is a good thing for element
variables, but exactly the same behavior is a bad thing for type variables?
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
Dieter Koenig1/Germany/IBM@IBMDE
23.06.2006 21:38 cc
wsbpel@lists.oasis-open.org, Alex
Yiu <alex.yiu@oracle.com>
Subject
Re: [wsbpel] Issue - 280 - Proposal
to Vote
(resend the response to the correct email thread)
Hi Dieter,
-1 to the proposal.
Copied from the word doc:
======================
- paragraph after the fault catching rules, from:
Matching the type of a faultVariable to fault data as mentioned in points
#1 and #4 above is more restrictive than in points #2 and #5. A WSDL
message type variable can only match a WSDL message type fault data, while
an element variable can only match element based fault data. They match
only when their QNames are identical.
to:
Matching the declared type of a faultVariable to the declared type of the
fault data as mentioned in points #1 and #4 above is based on QName
matching of the declared variable types. This means, if a variable declared
with element type tns:bar is thrown, a catch with faultElement="tns:bar"
will catch it.
======================
As mentioned before, this proposal essentially create a psuedo-data-model
in BPEL which treat type always *static*.
This static psudo-data-model significantly contradicts:
*Any* data typing language that supports inheritance and polymorphism
including:
e.g.: XML Schema: "extends" and "xsi:type" feature
XPath 2.0 / XQuery 1.0 data model: where the type is dynamic, not
static
See "treat as" and "cast as" operations:
http://www.w3.org/TR/xpath20/#id-cast
http://www.w3.org/TR/xpath20/#id-treat
The not-well-founded urge to quest for skin-deep-level symmetry in <catch>
will abrupt the future adoption of other standards.
I would prefer Mark Ford's original proposal.
Mark Ford's proposal is just a bug fix/clarification, while Dieter's
proposal is definitely a new feature. That really violates the practice
that we should ONLY do clarification/bug-fix in this stage of
specification.
And, this <catch> with "type" discussion was discussed way back when Yaron
suggested to add "element" . It was a conscious decision that we do NOT add
type related feature to <catch> to stay way from type related complexities:
inheritance and polymorphism complexities.
Thank you!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Also as Word-File to highlight the changes:
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18915/Issue%20280%20-%20Proposal%20for%20Vote.doc
Proposal for vote (Issue 280)
Change the syntax descriptions of <catch> from:
<catch faultName="QName"? faultVariable="NCName"?
faultMessageType="QName"?
faultElement="QName"?>*
activity
</catch>
to:
<catch faultName="QName"? faultVariable="NCName"?
faultMessageType="QName"?
faultElement="QName"?
faultType="QName"?>*
activity
</catch>
This change has to be done in:
- Section 5.2, basic structure of <process>
- Section 5.2, basic structure of <invoke>)
- Section 10.3, syntax of the <invoke> activity
- Section 12.5, syntax of <faultHandlers>
Change in section 12.5:
- paragraph 7 and 8, from:
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 data to be caught is a WSDL
message
then the faultMessageType attribute is used to specify the message
type’s QName. If the data to be caught is a XML element then the
faultElement attribute is used to specify the element definition’s
QName.
To have a defined type associated with the fault variable, the
faultVariable attribute MUST only be used if either the
faultMessageType
or faultElement attributes, but not both, accompany it. The
faultMessageType and faultElement attributes MUST NOT be used
unless
accompanied by faultVariable attribute.
to:
Data thrown with a fault can be a WSDL message type, a XML schema
element or a XML schema type. 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 data to be
caught
is a WSDL message then the faultMessageType attribute is used to
specify
the message type’s QName. If the data to be caught is a XML schema
element, then the faultElement attribute is used to specify the
element
declaration's QName. If the data to be caught is a XML schema
type, then
the faultType attribute is used to specify the type definition’s
QName.
To have a defined type associated with the fault variable, the
faultVariable attribute MUST only be used if exactly one of the
faultMessageType, faultElement or faultType attributes accompany
it. The
faultMessageType, faultElement or faultType attributes MUST NOT be
used
unless accompanied by faultVariable attribute.
- fault catching rule 1 with associated data, from:
If there is a <catch> construct with a matching faultName value
that has
a faultVariable whose type matches the type of the fault data then
the
fault is passed to the identified <catch> construct.
to:
If there is a <catch> construct with a matching faultName value
that has
a faultVariable whose declared type matches the declared type of
the
fault data then the fault is passed to the identified <catch>
construct.
- fault catching rule 4 with associated data, from:
Otherwise if there is a <catch> construct without a faultName
attribute
that has a faultVariable whose type matches the type of the fault
data
then the fault is passed to the identified <catch> construct.
to:
Otherwise if there is a <catch> construct without a faultName
attribute
that has a faultVariable whose declared type matches the declared
type
of the fault data then the fault is passed to the identified
<catch>
construct.
- paragraph after the fault catching rules, from:
Matching the type of a faultVariable to fault data as mentioned in
points #1 and #4 above is more restrictive than in points #2 and
#5. A
WSDL message type variable can only match a WSDL message type
fault
data, while an element variable can only match element based fault
data.
They match only when their QNames are identical.
to:
Matching the declared type of a faultVariable to the declared type
of
the fault data as mentioned in points #1 and #4 above is based on
QName
matching of the declared variable types. This means, if a variable
declared with element type tns:bar is thrown, a catch with
faultElement="tns:bar" will catch it.
- paragraph after the fault catching example, from:
Assume that a fault named ”x:foo” is thrown from within the scope
to
which this <faultHandlers> construct is attached. The first
<catch> will
be selected if the fault carries no fault data. If there is fault
data
associated with the fault, the third <catch> will be selected if
and
only if the type of the fault’s data matches the type of variable
“bar”,
otherwise the <catchAll> fault handler will be selected. Finally,
a
fault with a fault variable whose type matches the type of “bar”
and
whose name is not “x:foo” will be processed by the second catch.
All
other faults will be processed by the <catchAll> fault handler.
to:
Assume that a fault named ”x:foo” is thrown from within the scope
to
which this <faultHandlers> construct is attached. The first
<catch> will
be selected if the fault carries no fault data. If there is fault
data
associated with the fault, the third <catch> will be selected if
and
only if the declared type of the fault’s data matches the declared
type
of variable “bar”, otherwise the <catchAll> fault handler will be
selected. Finally, a fault with a fault variable whose declared
type
matches the declared type of variable “bar” and whose name is not
“x:foo” will be processed by the second catch. All other faults
will be
processed by the <catchAll> fault handler.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]