Hi all,
This is amended proposal that got voted on:
-----------------------------------------------
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 fail any of those static analysis check. Please note that such analysis might in some cases prevent the use of processes that would not, in fact, create situations with errors, 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.
A WS-BPEL implementation MAY perform extra static analysis checking beyond the basic static analysis required by this specification to signal warnings or even reject process definitions. Such an implementation SHOULD be configurable to disable these non-specified static analysis checks.
-----------------------------------------------
Regards,
Alex Yiu
Alex Yiu wrote:
Hi Danny,
I am OK with your suggested rephrasing of the last sentence of the
second paragraph.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I need to give this some thought, but right off the bat, I would remove
any notion of a configurable switch to stay consistent with not
mentioning the elephant. Maybe even just rephrase to:
Such an implementation SHOULD be
configurable
to disable these non-specified static analysis checks.
Alex Yiu wrote:
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.
A WS-BPEL implementation MAY
perform
extra static analysis checking beyond the basic static analysis
required by this specification to signal warnings or even reject
process definitions. Such an implementation SHOULD provide a
configurable switch to disable these non-basic static analysis.
Note:
- I avoided the term "pessimistic" vs "optimistic". Without a clear definition
what "pessimistic" and "optimistic" mean precisely in the BPEL
context, using those terms would just create unnecessary confusion and
contention.
- The spec should just point out the cases of static checking
those clear violation of spec semantics. (aka black cases).
Definition of grey cases should rest on vendors' shoulders. Grey area
cases would diminish as the spec and technology mature.
I hope the above draft proposal sounds right to most people on the TC.
Thanks!
Regards,
Alex Yiu
---------------------------------------------------------------------
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
|