[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/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]