RE: [wsbpel] Issue - 72 - Revised proposal to discuss

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

Ugo,

Thanks for you quick reply. Comments interspersed

> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> Sent: 03 November 2003 17:29
> To: Furniss, Peter; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue - 72 - Revised proposal to discuss
> 
> 
> Hi Peter,
> 
> Two comments on your point P below:
> 
> - I don't understand why the word "erroneous" has been
> dropped. Cases like the ones I mentioned in the past where 
> the syntax used in the WSDL 1.1 spec is inconsistent with the 
> syntax defined in the corresponding schema cannot be 
> classified as underspecified (in a way they are "overspecified").

Last time this got batted around was between you and Satish, ending with
http://lists.oasis-open.org/archives/wsbpel/200310/msg00266.html , where
Satish "recommended against erroneous". I took your silence then as
assent.

> - The phrase "will normally be followed" is weak and
> ambiguous (are there cases when it might not be followed? 
> what type of cases are those? etc.)

yes, it was meant to be a bit vague.  Remember this is just guidance for
our own future deliberations.  Making this text stronger would be making
it a kind of constitutional clause (the TC shall pass no resolution
contradicting BP 1.0) which would "win" in a fight with a particular
resolution that was contradicting BP 1.0. In such a case, the "normally
be followed" would force consideration of the un-BP-ness, but that could
be weighed in the balance with whatever was motivating the
contradiction.

Actually, I would be very surprised if there were motive for a real
contradiction. The vagueness was much more intended to avoid having to
lay out precisely how to deal with cases where BP deals with an
looseness by choosing one of several possibilities. It's imaginable that
BPEL would want to keep the flexibility available for the wider cases
where the totality was out of BP scope but this particular bit (on wsdl,
say) was apparently in scope. Rather than trying to write some
water-tight text to capture this for inclusion in what is only guidance
to ourselves, it seemed simpler to say "normally" and see if there
really is a bridge to cross in the future.

Peter

> Ugo
> 
> > -----Original Message-----
> > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> > Sent: Monday, November 03, 2003 9:00 AM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Issue - 72 - Revised proposal to discuss
> > 
> > 
> > After the last attempt, let's have another try.  I'm putting this 
> > out as for discussion - I'm hoping the proposal at the bottom will
> stabilise
> > enough by about Thursday to try for a vote on Wednesday week.
> > 
> > To achieve a consensus I think we will need to be more
> circumspect and
> > limited in how much we reference BP. The critical question
> seems to be
> > getting the scope situation clear. I believe people are agreed that
> > 
> > 	BPEL things using/operating with the BP 1.0 referenced
> specifiations
> > should be able to follow BP 1.0
> > 	BPEL things need use/operate with things that go beyond
> the BP 1.0
> > referenced specifications
> > 	BPEL should not perversely take a different interpretation of
> > underspecified WSDL 1.1 features from that taken by BP 1.0
> > 
> > (deliberately hand-waving on exactly what "things" covers).
> > 
> > I'm less sure on whether there is agreement on
> > 
> > 	BPEL things using/operating with the BP 1.0 referenced
> specifications
> > should be able to go beyond BP 1.0 limitations
> > 
> > 
> > One position would just be to say "BPEL implementations stand or 
> > fall on their compliance to BP 1.0 as WSDL, SOAP etc implmentations,

> > in the
> > (common) case that they are implementations of such. BPEL
> as such has
> > nothing to say on BP 1.0, and the fact that a BPEL
> implementation also
> > implements the BP 1.0-referenced specs does not impact the BPEL 
> > aspects.". Effectively wash our hands of the whole matter.
> (There have
> > been strong statements against this sort of position in the previous
> > discussions)
> > 
> > 
> > How about, as a proposed resolution:
> > 
> > Given that the scope of BP is confined to the specifications it
> > references, and that BPEL is of wider application:
> > 
> > P) 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 features will normally be followed.
> > 
> > Q) 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.
> > 
> > R) The requirement (or non-requirement) of BP 1.0
> compliance of BPEL
> > engines or deployed processes is not affected by their use of BPEL.
> > 
> > 
> > Better phrasing of any of those welcome.  They are
> deliberately silent
> > on some points that could be expanded.
> > 
> > The "if possible" on Q is intended to allow a use-case that
> deals with
> > handling non-BP 1.0 web-services, if anyone wants to define
> such. Such
> > a use-case clearly cannot have BP 1.0 compliant artifacts and 
> > achieve it's purpose as a use-case.
> > 
> > 
> > 
> > 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.
> 
>