+1
Mark,
That is a good catch.
I would suggest to drop
"forEachCounterError" fault and use "invalidExpressionValue" fault
consistently. How does that sound to you?
Thanks!
Regards, Alex
Yiu
Mark Ford wrote:
How does your proposal affect the existing fault:
bpel:forEachCounterError? The spec currently has this fault thrown during the
evaluation of the forEach's start and final counter values. It makes no
mention of the completion condition expression.
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Friday, March 31, 2006 10:34 AM To: Alex
Yiu Cc: wsbpeltc; 'Dieter Koenig1'; Simon D Moser; Danny van der
Rijn Subject: [wsbpel] Issue 252 - proposal for
vote
Hi all,
This is the *formal* proposal for
*vote*.
The proposal is virtually the same compared with my last email
with some minor supplement texts are added at the end.
In Section
"8.3. Expressions" After this paragraph:
------------------------------- WS-BPEL uses several types of
expressions, as follows (relevant usage contexts are listed in parentheses):
- Boolean expressions (transition, join, while, and if conditions)
- Deadline expressions (until expression of onAlarm and wait)
- Duration expressions (for expression of onAlarm and wait, repeatEvery
expression of onAlarm)
- Unsigned Integer expressions (startCounterValue, finalCounterValue, and
branches in forEach)
- General expressions (assign)
-------------------------------
Add the following paragraph:
------------------------------- When the above first four types of
expressions are being used, the corresponding expressions SHOULD return values
which are valid according to the corresponding XML Schema types:
- Boolean expressions should return valid values of xsd:boolean
- Deadline expressions should return valid values of xsd:date and
xsd:dateTime
- Duration expressions should return valid values of xsd:duration
- Unsigned Integer expressions should return valid values of
xsd:unsignedInt
Otherwise, a bpel:invalidExpressionValue fault
SHOULD be thrown. Implicit data conversion or casting MAY be applied when
computing returned values from expressions, based on the data model or type
conversion semantics established in the underlying expression language.
The following values conversion and validity checking semantics MUST
be applied when WS-BPEL's default binding to XPath 1.0
("urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0") is used as the expression
language:
- For WS-BPEL Boolean expressions, XPath's boolean(object) function is
used to convert the expression result into a Boolean value if needed.
- For WS-BPEL Deadline expressions, XPath's string(object) function is
used to convert the expression result into a string value if needed. The
string value MUST be valid values of xsd:date and xsd:dateTime. Otherwise, a
bpel:invalidExpressionValue fault MUST be thrown.
- For WS-BPEL Duration expressions, XPath's string(object) function is
used to convert the expression result into a string value if needed. The
string value MUST be valid values of xsd:duration. Otherwise, a
bpel:invalidExpressionValue fault MUST be thrown.
- For WS-BPEL Unsigned Integer expressions, XPath's number(object)
function is used to convert the expression result into a numeric value if
needed. The numeric value MUST be valid values of xsd:unsignedInt (i.e.
neither negative or NaN and it must be an integer value). Otherwise, a
bpel:invalidExpressionValue fault MUST be thrown.
-------------------------------
Add the following fault
description to Appendix
A: ------------------------------- invalidExpressionValue fault throw
when an expression used within a WS-BPEL construct (non-<assign>
construct) returns an invalid value (for example, the branches expression
within <forEach> returns
-1) -------------------------------
Thanks!
Regards, Alex
Yiu
|