[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 9 - Rought Draft of a proposal to vote
Issue 84 was passed to provide exactly the list you asked for. Alex Yiu wrote: > > I would like to mention some pre-conditions in order to make this > proposal enforceable. > > The proposal changes static analysis from "pessimistic" to "optimistic". > I tend to think those terms are enforceable only when the spec have a > clear list of static analysis semantics, which has two output choices - > error or warning. The list defineds what checking logic will issue error > ... (e.g. spelling mistake in variable name in receive) what checking > logic will issue warnings only (e.g. assign is trying to assign a string > value to a number variable) (that is the optimistic part). > > If the list of static analysis mentioned by the spec are for fatal error > only, then the "optimistic" term may not be that enforceable. This > proposal may become guidelines instead of rules. > > Anyhow, I agree that we should visit the terms "pessimistic" vs > "optimistic" in that paragraph. > > > > Regards, > Alex Yiu > > John Evdemon wrote: > >> ++1 - no more wiggle room. Thank you for the clarification. >> >> >> >> >> >>> -----Original Message----- >>> From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Friday, August >>> 13, 2004 1:03 PM >>> To: John Evdemon >>> Cc: wsbpeltc >>> Subject: Re: [wsbpel] Issue 9 - Rought Draft of a proposal to vote >>> >>> Fair enough. How'z about: >>> 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 MUST 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. >>> >>> Yaron >>> >>> >>> John Evdemon wrote: >>> >>> >>> >>>> +1, although "could potentially execute" is a bit fuzzy. >>>> >>>> >>>> >>>> > -----Original Message----- >>>> > From: Yaron Y. Goland [mailto:ygoland@bea.com] >>>> > Sent: Thursday, August 12, 2004 4:51 PM >>>> > To: wsbpeltc >>>> > Subject: [wsbpel] Issue 9 - Rought Draft of a proposal to vote >>>> > >>>> > Here is a rough draft for a proposal for vote for issue >>> >>> 9. Thoughts? >>> >>> >>>> > comments? >>>> > Thanks, >>>> > Yaron >>>> > >>>> > Section 5: >>>> > >>>> > Change: 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 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: 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 MUST be performed optimistically, that is, if a >>>> > process could >>>> > potentially execute correctly then the process MUST be >>> >>> accepted for >>> >>> >>>> > execution. >>>> > >>>> > To unsubscribe from this mailing list (and be removed from >>>> > the roster of the OASIS TC), go to >>>> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le >>>> ave_workgroup.php. >>>> > >>>> > >>>> >>>> >> >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]