This issue has been added to the wsbpel issue list with a
status of "open". The TC agreed to accept the issue before it was added to
the issue list.
The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC
pages on a regular basis. The current edition, as a TC document, is the
most recent version of the document entitled in the "Issues" folder of the
WSBPEL
TC document list - the next posting as a TC document will include this
issue. The list editor's working copy, which will normally include an issue
when it is announced, is available at this
constant URL.
Issue - 252 - Behaviour when return value of expressions is incorrect is
not defined
Status: open
Date added: 23 Mar
2006
Categories: Fault
handling
Submitter: Simon
Moser
Description: The fault that is thrown when incoming
and/or outgoing messages are schema validated SHOULD be the same as that of
the explicit validate activity.
In Section 8.3.x of the latest spec copy, there are multiple types of
expressions. None of these sections talks about what happens when the
(XPath) Expression doesn't evaluate to it's designated return value. That is
the expression itself gets evaluated successfully, so no fault is thrown
during evaluation, but the returned value is not of the type expected. For
illustration:
In a while activity, which demands a boolean expression, the return value
of the expression provided yields a non-boolean return type (that cannot be
detected by static analysis because sometimes the return value of e.g. an
XPATH expression is not known in advance. The spec should clearly state what
should happen in that case.
Submitters proposal:
A new standard fault bpel:invalidReturnType should be introduced and MUST
be thrown in these cases. This is similar to the "
mismatchedAssignmentFailure" except that the receiver is not the to-spec but
the engine itself.
This should be the case for
- 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)
That means that the associated activity
MUST check explicitly for schema compliance. That means
- Boolean expressions (transition, join, while, and if conditions) MUST
be checked against xsd:boolean
- Deadline expressions (until expression of onAlarm and wait) MUST be
checked against xsd:date or xsd:dateTime
- Duration expressions (for expression of onAlarm and wait, repeatEvery
expression of onAlarm) MUST be checked against xsd:duration
- Unsigned Integer expressions (startCounterValue, finalCounterValue,
and branches in forEach) MUST be checked against xsd:unsignedInt
Changes: 23 Mar 2006 - new issue
To comment on this issue (including whether it should be accepted),
please follow-up to this announcement on the wsbpel@lists.oasis-open.org
list (replying to this message should automatically send your message to
that list), or ensure the subject line as you send it starts "Issue -
252 - [anything]" or is a reply to such a message. If you want to formally
propose a resolution to an open issue, please start the subject line "Issue
- 252 - Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the address
for new issue submission is the sender of this announcement).
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php