Hi Danny,
Good ... we are converging.
I think we can use "MUST" language for XPath 1.0, while using "SHOULD"
language to give guidance for non-XPath 1.0 languages.
I agree with your "algorithms" in general. We just need to nail down
the exact language.
Regards,
Alex Yiu
Danny van der Rijn wrote:
OK, I think I see your point. I'm uncomfortable, however, giving
guidance only for XPath. Can we do something like:
"If the resulting expression does not match the expected type, then
bpel:foo MUST (SHOULD?) be thrown. The determination of whether the
expression matches the expected type is largely dependent on the
language binding. For urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0
the expectations are as follows:
Boolean: apply the boolean() function. True maps to true, false maps
to false. Any fault generated by the function generates
subLanguageExecutionFault
Unsigned Integer: apply the number() function. Any fault generated by
the function generatres subLanguageExecutionFault
Deadline, Duration: apply string() and interpret as dateTime or
duration
I'm not wedded to the above "algorithms," but would like something to
be there.
Danny
Alex Yiu wrote:
Hi Danny and others,
See comments inline:
[a]
Danny wrote:
Dieter's
language
"if an error is
detected then throw the new fault"
doesn't help too much for portability, IMO.
That I agree with that statement alone does not help that much, imho
[b]
Danny van der Rijn wrote:
I don't understand why you're going to so much detail. I sense that
you're trying to avoid requiring XPath (or non-default languages) to
have to convert to String in order that validation takes place.
Requiring that the String-serialized form comply with the relevant XSD,
though, doesn't require the actual conversion.
String-serialized is NOT exactly an expression-language independent
concept. For example, an XPath expression can return a nodelist (of
multiple nodes) and its "string-serialized" value definition that we
can refer to is: "string-value" of a node list as defined in XPath 1.0.
Existing expression languages may have already established how
conversion should work. E.g.:
XQuery 1.0: http://www.w3.org/TR/xquery/#id-ebv
XPath 1.0: http://www.w3.org/TR/xpath#function-boolean
If we define a conversion logic different from existing logic, it would
surprise existing expression language users. And, members of other WGs
(e.g. in W3C) would ask why the heck OASIS BPEL TC wants to re-invent a
wheel.
E.g. for XPath 1.0 expression, "$intVar and $strVar" will return true,
when intVar=3 and strVar="abc". If people drop "and $strVar" in the
expression, it should return true as well, not an error.
That's why I stress so much, if we pass a resolution for this issue.
The resolution should be scoped to XPath1.0-to-BPEL2.0 binding only. If
the resolution applies to non-XPath1.0 expression (e.g. XQuery 1.0), we
will likely define a semantic which is not incompatible with other
non-XPath 1.0 language.
The above description briefly sketch how a boolean expression should be
handled in XPath1.0-to-BPEL2.0 binding. That is, we should apply
boolean() to returned result of XPath 1.0 expression when used as a
boolean expression in BPEL 2.0.
We still need to describe other cases of expressions.
And, data objects are not my major concern now, as implicit data
objects conversion happens very often in XPath 1.0 expression in
general. My major concern is: our defined semantics should be somewhat
compatible with XPath 1.0.
We
already
go into some detail in 8.3 as to what the valid values for
the Expressions are. Unfortunately, we do it in terms of XPath, which
might not be the right thing to do. But if we fix that (if we need to)
then why can't we just say
"if the result of expression evaluation does not yield a result of the
expected Expression Type (see sections 8.3.x), the
bpel:newFaultForBadExpressions fault is thrown"?
Danny
[c]
I guess potentially we can use subLanguageExecutionFault here. That
would be more likely to be forward compatible with the casting related
error with XPath2.0/XQuery1.0.
Thanks!
Regards,
Alex Yiu
Alex
Yiu
wrote:
Hi DK and Danny,
Actually after more thinking, there may be a reasonable (not too heavy
handed) way to *define* when a runtime fault is thrown when values
from an expression cannot be converted into a target schema type.
However, I think we should address this definition in the context of default
XPath1.0-to-WSBPEL2.0 binding/handshaking (i.e.
"urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"), not in the context
of general WS-BPEL expression handling.
Because in XPath 2.0 data model, we have more tools to deal with this
problem in a more appropriate way.
For XPath1.0 data model, it has Number (Double) and Boolean to deal
with these expression.
Boolean expressions (in transition, join, while, and if
conditions)
Unsigned Integer expressions (in startCounterValue,
finalCounterValue, and branches in forEach)
On the other hand, we need to use string in XPath 1.0.
Deadline expressions (in until expression of onAlarm and wait)
Duration expressions (in for expression of onAlarm and wait,
repeatEvery expression of onAlarm)
Thanks!
Regards,
Alex Yiu
Dieter Koenig1 wrote:
Hi Alex, I am not sure if we have to go this far.
Today, we can detect and throw "mismatchedAssignmentFailure" when
incompatible types are detected (see 8.4.3) during assignment. This handles
any "type incompatibility between from-spec and to-spec".
The question is whether we can also detect and throw a new fault during
expression evaluation:
Boolean expressions (in transition, join, while, and if conditions)
Deadline expressions (in until expression of onAlarm and wait)
Duration expressions (in for expression of onAlarm and wait,
repeatEvery expression of onAlarm)
Unsigned Integer expressions (in startCounterValue,
finalCounterValue, and branches in forEach)
This would address any "type incompatibility between the specified
expression and the expectation of BPEL implementation". This situation
would otherwise lead to undefined behavior.
Instead of saying "the associated activity MUST check explicitly for schema
compliance", we may reduce the requirement and just say "if an error is
detected then throw the new fault".
Kind Regards
DK
Alex Yiu
<ALEX.YIU@ORACLE.
COM> To
Danny van der Rijn
26.03.2006 08:58 <dannyv@tibco.com>,
wsbpel@lists.oasis-open.org
cc
Alex Yiu <alex.yiu@ORACLE.COM>
Subject
Re: [wsbpel] Issue - 252 -
Behaviour when return value of
expressions is incorrect is not
defined
If we want to handle this issue right, we would likely either create
dependencies on XQuery1.0/XPath2.0 spec or duplicate chunks of those specs
in this bpel spec.
Thanks!
Regards,
Alex Yiu
>From Danny van der Rijn <dannyv@tibco.com>
Sent Fri 3/24/2006 1:03 PM
To wsbpel@lists.oasis-open.org
Subject Re: [wsbpel] Issue - 252 - Behaviour when return value of
expressions is incorrect is not defined
I don't think we agreed to open this issue, did we?
ws-bpel issues list editor wrote:
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
---------------------------------------------------------------------
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
|