[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
Things like misspellings can be caught by a general rule requiring schema compliance. This is a topic I will be revisiting in the very near future. Satish Thatte wrote: > I agree with Alex that basing a definition on execution paths alone is > problematic, unless we separately define and require internal > consistency checks which we list exhaustively (misspelt variable names > being the simplest example of consistency errors). > > Satish > > > -----Original Message----- > From: Alex Yiu [mailto:alex.yiu@oracle.com] > Sent: Tuesday, August 17, 2004 1:34 PM > To: John Evdemon > Cc: ygoland@bea.com; wsbpeltc > Subject: Re: [wsbpel] Issue 9 - Rought Draft of a proposal to vote > > > 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_workgr > oup.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_workgr > oup.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]