RE: [wsbpel] RE: [spell] Issue - 72 - Proposal to vote

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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.
> 
>