OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 252 - Behaviour when return value of expressionsis incorrect is not defined


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.

Dieter's language
"if an error is
detected then throw the new fault"
doesn't help too much for portability, IMO.

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

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



  



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]