Hi Peter,
Thanks for letting us know about the pattern matching logic in your
script.
For this particular issue 252, I do plan to make it into a formal
proposal today. (I will send out a formal email - with subject line as
"issue 252 - proposal for vote" a moment later.)
So we can vote for it next week.
Regards,
Alex Yiu
Peter Furniss wrote:
Friends - please don't start
subject lines "Issue NNN - propos" unless it is meant to be a formal
proposal. The scripts set
things up to change the
state to proposed and I have to edit them back again. "Issue NNN -
suggested proposal" or "Issue NNN - discussion proposal" will be
treated as just simple follow-ups.
I take it this issue was
opened yesterday then ? Sorry I wasn't able to stay on the call.
Peter
Hi all,
This is the proposal for discussion. If I don't hear any major
feedback, I would move this into the formal proposal to vote before the
end of week. Thanks!
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). Otherwise, a
bpel:invalidExpressionValue fault MUST be thrown.
-------------------------------
Thanks!
Regards,
Alex Yiu
|