[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 9 - proposaldraft for discussion
Hi all, As mentioned in the conf call last week, the way I interpret Yaron's proposal more than a year ago was: ... http://lists.oasis-open.org/archives/wsbpel/200409/msg00167.html To: BPEL4WS takes it as a general principle that compliant implementations MAY choose to perform static analysis to detect and reject process definitions that may have undefined semantics. Such analysis SHOULD be performed optimistically, that is, assuming the process has no syntactic errors then if there exists at least one execution path from each start activity in the process that can complete successfully then the process MUST be accepted for execution. ... basically to suggest (RFC SHOULD) WS-BPEL implementation become a scripting engine like interpreter. E.g. say there is an if-then-else block and the else-block has a syntactic correct process definition (i.e. passing XSD validation), a WS-BPEL process should still accept it, no matter how serious semantic error the else-block code contains (e.g. failure to resolve variables or partnerLinks). I am not sure this is a preferred direction that the spec should indicate to implementators, while I understand Yaron's intention to ensure certain forms of portability. Here is my attempt (as Diane requested) to rephrase that paragraph to encourage a higher level of portability without resulting into encouraging interpreter implementation. From: WS-BPEL takes it as a general principle that conformant implementations MAY choose to perform static analysis to detect and reject process definitions that may have undefined semantics. Such analysis is necessarily pessimistic and therefore might in some cases prevent the use of processes that would not, in fact, create situations with undefined semantics, either in specific uses or in any use.To: WS-BPEL takes it as a general principle that conformant implementations MUST perform basic static analysis listed in Appendix [TBD - xref to Issue 84] to detect and reject process definitions that has undefined semantics. Please note that such analysis might in some cases prevent the use of processes that would not, in fact, create situations with undefined semantics, either in specific uses or in any use. For example, a WS-BPEL implementation will reject a process with <invoke> activity referring to an undefined variable, where the <invoke> activity may not be actually reached during execution of the process. Note:
I hope the above draft proposal sounds right to most people on the TC. Thanks! Regards, Alex Yiu |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]