[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote
Actually I see a bigger difference between SHOULD and MAY than you do. In particular, MAY does not imply it's a good idea (see definition of MAY in RFC2119). > -----Original Message----- > From: Danny van der Rijn [mailto:dannyv@tibco.com] > Sent: Tuesday, November 11, 2003 1:09 PM > To: wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote > > > i wouldn't mind not saying anything at all. if we used MAY, > we are pointing > out that it's a good idea. which really isn't that much less > than SHOULD > anyway, is it? > > ----- Original Message ----- > From: "Ugo Corda" <UCorda@SeeBeyond.com> > To: "Danny van der Rijn" <dannyv@tibco.com>; > <wsbpel@lists.oasis-open.org> > Sent: Tuesday, November 11, 2003 1:03 PM > Subject: RE: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote > > > Danny, > If we used MAY in 'c' we might as well not say anything at > all. What would > be the difference at that point? > > Ugo > > > -----Original Message----- > > From: Danny van der Rijn [mailto:dannyv@tibco.com] > > Sent: Tuesday, November 11, 2003 12:51 PM > > To: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote > > > > > > and i would further reduce paco's SHOULD to a MAY. > > > > danny > > > > ----- Original Message ----- > > From: "Francisco Curbera" <curbera@us.ibm.com> > > To: <wsbpel@lists.oasis-open.org> > > Sent: Tuesday, November 11, 2003 12:36 PM > > Subject: RE: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote > > > > > > > > > > > > > > > > > > > I like the modifications proposed by Peter for a) and b); I > > think they > > make > > > an acceptable proposal. They state desirable guidelines without > > > unnecessarily constraining the language's flexibility or > > its deployment > > > scenarios. > > > > > > For clarity, I think this is what the latest modifications > > amount to: > > > > > > a) In developing the BPEL language, where reference is made to > > > specifications that are in BP 1.0 scope, the BP 1.0 > > interpretations will > > > normally be followed. > > > > > > (I don't really understand the reason for Ugo's replacement of > > > recommendations by requirements in a).) > > > > > > b) Where use-cases and use-case artifacts are in BP 1.0 > > scope (i.e. using > > > referenced specifications) they will be BP 1.0 compliant, > > if possible. > > > > > > As for c), I had proposed that we use SHOULD instead of > > SHALL/MUST because > > > I think it is not BPEL's business to dictate the non-BPEL > > aspects of the > > > runtime. I also find a bit vague the notion of "BP 1.0 > > scenario". Finally, > > > the expression "will only send BP 1.0 compliant messages" > > seems to leave > > > out processes that interact with both legacy (pre BP 1.0) > and BP 1.0 > > > compliant services. I think we really want the engine to > be able to > > operate > > > in BP 1.0 compliant mode when required - in particular, > with certain > > > partners but maybe not with others. > > > > > > So I would suggest the following: > > > > > > c) All BPEL implementations SHOULD be configurable such > > that they will can > > > participate in BP1.0 compliant interactions. A BPEL > > implementation MAY > > > allow the BP 1.0 configuration to be disabled, even for scenarios > > > encompassed by BP 1.0. > > > > > > Paco > > > > > > > > > > > > > > > > > > > > "Furniss, Peter" > > > <Peter.Furniss@chor To: > > "Ugo Corda" > > <UCorda@SeeBeyond.com>, <ygoland@bea.com>, > > > eology.com> > > <wsbpel@lists.oasis-open.org> > > > cc: > > > 11/11/2003 05:10 AM Subject: > > RE: [wsbpel] > > RE: [spell] Issue - 72 - Proposal to vote > > > > > > > > > > > > > > > > > > Someone (not me) could indeed spend the time to go through > > BP 1.0a and > > > work out which of its requirements should apply to the BPEL > > language, > > > and propose that list as a detailed resolution of issue 72. > > However, I > > > doubt if it's worth the effort. > > > > > > The alternative, which I tried to state in my a), is just > > to have as a > > > guideline that we will follow BP 1.0. Then in any future > > discussion on a > > > particular point, if a proposed text is contrary to R1234 > > (say), then > > > it's going to take a really well-argued case to use that > > text. But we > > > don't need to go trawling through BP 1.0 speculatively - we > > can rely on > > > ourselves as a TC (and potentially the wider community of > > reviewers of > > > our drafts) to point out collisions with BP 1.0. > > > > > > But perhaps I've over-restricted a), constraining it both to > > > "underspecified and erroneous" AND making it a guideline, > > not a rigid > > > rule with "normally be followed". Would omitting the > > "underspecified and > > > erroneous features", but keeping the "normally ..." cover > > the point ? > > > > > > a) In developing the BPEL language, where > > reference is made > > to > > > specifications that are in BP 1.0 scope, > > > the BP 1.0 interpretations will normally be followed. > > > > > > or leave it. > > > > > > or someone can propose the definitive list. > > > > > > Peter > > > > > > > -----Original Message----- > > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > > > Sent: 10 November 2003 22:20 > > > > To: ygoland@bea.com; Furniss, Peter; wsbpel@lists.oasis-open.org > > > > Subject: RE: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote > > > > > > > > > > > > Yaron, > > > > > > > > The specific example you bring up (R1000) is not a good one > > > > because it relates to SOAP requirements, while point 'a' > > > > relates to the BPEL language (which has no explicit > > > > connection to SOAP). > > > > > > > > Besides that, you are making a good point. There are probably > > > > aspects of BP 1.0 requirements (in those areas that do apply > > > > to the BPEL language scope) that cannot be classified as > > > > fixing underspecified or erroneous features (even though I > > > > don't have any specific example off the top of my head). > > > > > > > > My personal answer is that point 'a' would also apply to > > > > those requirements (and I would agree that, if we take this > > > > interpretation, point 'a' would have to be better qualified). > > > > The reason is that point 'a', as I see it, is about the BPEL > > > > language being consistent with all the interoperability > > > > requirements of BP 1.0 that fall within the scope of the BPEL > > > > language itself (mostly WSDL-related requirements). > > > > > > > > Ugo > > > > > > > > > -----Original Message----- > > > > > From: Yaron Goland [mailto:ygoland@bea.com] > > > > > Sent: Monday, November 10, 2003 1:54 PM > > > > > To: 'Furniss, Peter'; wsbpel@lists.oasis-open.org > > > > > Subject: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote > > > > > > > > > > > > > > > I opened BP 1.0a and randomly picked an entry, I got R1000 > > > > > which restricts which elements may appear in a SOAP fault. > > > > > > > > > > Is R1000 a fix for an under specified or erroneous feature in > > > > > the SOAP spec or an editorial decision by WS-I that > > > > > additional elements would make it harder to achieve > > > > interoperability? > > > > > > > > > > If the former, then per point 'a', BPEL must follow it, if > > > > > the later then it is merely a BPEL guideline. The > > > > > ramifications on interoperability are profound. Who exactly > > > > > gets to decide what constitutes a fix for an under specified > > > > > or erroneous feature and what is just an editorial > > decision by WS-I? > > > > > > > > > > So before this group can vote on point 'a' we need to get > > > > > clarification as to *exactly* which points in the WS-I spec > > > > > would be considered requirements for BPEL under point 'a'. > > > > > > > > > > I also would propose that we change 'c' to read: All BPEL > > > > > implementations MUST be configurable such that they will only > > > > > send and receive messages in a manner compliant with BP 1.0 > > > > > for those messaging scenarios encompassed by BP 1.0. But, a > > > > > BPEL implementation MAY allow the BP 1.0 configuration to be > > > > > disabled, even for scenarios encompassed by BP 1.0. > > > > > > > > > > Yaron > > > > > > > > > > > -----Original Message----- > > > > > > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > > > > > > Sent: Saturday, November 08, 2003 4:13 AM > > > > > > To: wsbpel@lists.oasis-open.org > > > > > > Subject: [wsbpel] Issue - 72 - Proposal to vote > > > > > > > > > > > > > > > > > > Proposed resolution for issue 72: > > > > > > > > > > > > > > > > > > Given that the scope of BP is confined to the > > specifications it > > > > > > references, and that BPEL is of wider application: > > > > > > > > > > > > a) In developing the BPEL language, where reference > is made to > > > > > > specifications that are in BP 1.0 scope, the BP 1.0 > > > > > interpretations of > > > > > > underspecified or erroneous features will normally be > > followed. > > > > > > > > > > > > b) Where use-cases and use-case artifacts are in BP 1.0 > > > > scope (i.e. > > > > > > using referenced specifications) they will be BP 1.0 > > > > compliant, if > > > > > > possible. > > > > > > > > > > > > c) The requirement (or non-requirement) of BP 1.0 > > > > compliance of BPEL > > > > > > engines or deployed processes is not affected by their > > > > use of BPEL. > > > > > > > > > > > > --- > > > > > > > > > > > > See previous discussion ( > > > > > > > > > > > > > > > http://www.choreology.com/external/WS_BPEL_iss> > > ues_list.html#Issue72 > > > ) > > > > > > for more explanation. The only change from the proposal for > > > > > discussion > > > > > > in > > > > > > > http://lists.oasis-open.org/archives/wsbpel/200311/msg00018.html is > > > > > > the addition of "or erroneous" in a). > > > > > > > > > > > > > > > > > > To maximise our chances of getting closure on this before > > > > > 2004, if the > > > > > > above is unsatisfactory, please give proposed amendment (or > > > > > > alternative > > > > > > text), not just expressions of discomfort. Please! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Peter > > > > > > > > > > > > ------------------------------------------ > > > > > > Peter Furniss > > > > > > Chief Scientist, Choreology Ltd > > > > > > > > > > > > Cohesions 1.0 (TM) > > > > > > Business transaction management software for application > > > > > > coordination > > > > > > > > > > > > web: http://www.choreology.com > > > > > > email: peter.furniss@choreology.com > > > > > > phone: +44 870 739 0066 <-- new, from 4 August 2003 > > > > > > mobile: +44 7951 536168 > > > > > > > > > > > > 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/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/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. 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]