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] 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/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]