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 9 - proposal draft for discussion



Vinki and I took turns to go over the spec and collect places where static
analysis (SA) is required or might be granted. A draft of a SA appendix is
attached. It is of course only a first draft we can use for a discussion of
issue 9 on Monday.

About how the list was compiled: Vinki went included statements where
"static analysis" is explicitly requested. After that I went over places
where MUST/must occurs. This forced me to make judgements about which of
those MUSTs would require SA; in particular, I tried not to include purely
syntactic statements (i.e. about the "form" of individual elements), even
if some of those cannot be represented in XML Schema. The boundary between
what is pure syntax and what is not is relatively fuzzy so I believe we'll
be discussing that point.

Paco

(See attached file: Appendix - Static Analysis.doc)




                                                                       
                      Alex Yiu                                         
                      <alex.yiu@oracle.        To:       Danny van der Rijn <dannyv@tibco.com>
                      com>                     cc:       wsbpeltc <wsbpel@lists.oasis-open.org>, Alex Yiu <alex.yiu@oracle.com>
                                               Subject:  Re: [wsbpel] Issue 9 - proposal draft  for discussion
                      03/13/2006 03:10                                 
                      PM                                               
                                                                       





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

Appendix - Static Analysis.doc



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