+1.
Please, let us not utter the evil four letter incantation rhyming with
ROPE lest the demons it wakes destroy us all.
-maciej
On Wed, 2005-02-16 at 09:18 -0800, Satish Thatte wrote:
> The question is: implementer of what? We are only addressing the
> implementer of BPEL who is not even required to be aware of the SOAP
> binding. There are clearly bindings that would make this unambiguous
> but those again are out of scope for the metadata the BPEL implementer
> is concerned with.
>
> This is the essence of my objection: addressing binding issues in the
> spec *unnecessarily* expands the scope of what we are concerned with.
> It is clearly possible to implement BPEL in such a way that the binding
> layer is cleanly separated and the "BPEL engine" is not even invoked
> until an abstract message has been constructed successfully.
>
> Satish
>
> -----Original Message-----
> From: Yaron Y. Goland [mailto:]
> Sent: Monday, February 14, 2005 2:30 PM
> To: Satish Thatte
> Cc: wsbpeltc
> Subject: Re: [wsbpel] Issue 154 - Proposal For Vote
>
> An implementer creates a test message involving two complex types, both
> of which are unbounded sequences of the same element type. When encoded
> in a SOAP message there is no binding level definition that lets the
> engine figure out which parts of the SOAP message should go into one
> part versus another.
>
> The implementer, looking at this completely legal WSDL case then has to
> ask themselves 'how should I handle this'?
>
> The answer is - by rejecting the binding, it's ambiguous.
>
> But where in the spec can they find that ever stated? The answer is -
> they can't.
>
> So the implementer is left to wonder if:
> A) There is some part of the spec that addresses the situation but they
> can't find it
> B) The spec has a bug and meant to provide a way to handle the situation
>
> but forgot
> C) BPEL intentionally doesn't address the situation because it is out of
>
> scope
>
> There is nothing in the spec which I can find that would lead a common
> implementer to know which of the three above options to choose.
>
> By adding in a simple paragraph we resolve the situation nicely and make
>
> it absolutely clear that this type of scenario is not something BPEL
> deals with.
>
> BTW, I get this kind of question from my testing team all the time and
> is where a number of the clarification issues I have raised have come
> from.
>
> Yaron
>
> Satish Thatte wrote:
> > Can you give me an example where a BPEL engine implementer would get
> > confused about what the BPEL engine's responsibilities are based on
> > today's spec?
> >
> > -----Original Message-----
> > From: Yaron Y. Goland [mailto:]
> > Sent: Monday, February 14, 2005 12:35 PM
> > To: Satish Thatte
> > Cc: wsbpeltc
> > Subject: Re: [wsbpel] Issue 154 - Proposal For Vote
> >
> > I'm unclear how you can be so sure that an implementer will come to
> the
> > same conclusion that as reached in the second paragraph of your mail.
> > After all, there are a number of techniques we could have chosen to
> use
> > at the abstract layer that would have dealt with some of the
> ambiguities
> >
> > at the binding layer. But we wisely choose not to try and disambiguate
> > things at the abstract layer because it would be a nasty mess. But
> that
> > decision is not recorded anywhere in the spec. By explicitly stating
> > that we will not try to disambiguate things at the abstract layer we
> > create a clearer specification.
> >
> > Put another way, what may be clear in your mind will most certainly
> not
> > be clear in the minds of implementers who will not have your
> background
> > in the spec.
> >
> > Yaron
> >
> > Satish Thatte wrote:
> > > -1
> > >
> > > I think this additional language adds no useful content to the
> > > specification. All it says is: WSDL has binding problems and they
> are
> > > WSDL's problems not ours.
> > >
> > >
> > > Since we only deal with abstract port types and abstract message
> > types,
> > > it is absolutely clear already that it is someone else's
> > responsibility
> > > to "make things right" from the wire layer to the abstract layer.
> > >
> > > Satish
> > >
> > > -----Original Message-----
> > > From: Yaron Y. Goland [mailto:]
> > > Sent: Friday, February 11, 2005 12:47 PM
> > > To: wsbpeltc
> > > Subject: [wsbpel] Issue 154 - Proposal For Vote
> > >
> > > Issue 154 - doc/lit & multiple body parts
> > >
> > > Proposal: To put in language that makes explicit what is currently
> > > implicit in the BPEL spec, that it is the binding layer's job to
> > > decompose the physical message into the portType definition.
> > >
> > > Rationale: One of the more basic flaws in spec writing is to make
> > > implicit assumptions. By doing so spec implementers are always left
> in
> > > the dark because they may not share the same implicit assumptions
> as
> > the
> > >
> > > spec authors. The fix is to make the implicit assumption explicit
> > which
> > > is what this proposal does. Note, however, that this proposal
> causes
> > no
> > > normative changes to BPEL's current behavior, it just makes what
> was
> > > implicit, explicit.
> > >
> > > Changes Required:
> > >
> > > Section 3 -
> > >
> > > Insert new paragraph after the paragraph that begins "While WS-BPEL
> > > attempts to provide as much compatibility with WSDL 1.1 as
> > possible..."
> > >
> > > BPEL assumes that the WSDL binding layer is able to decompose
> incoming
> > > messages into the parts specified by the WSDL message definition.
> > > However it is know that certain combinations of message definitions
> > and
> > > bindings, including ones defined in the WSDL standard itself,
> cannot
> > be
> > > decomposed in any standard way. For example, a multi-part WSDL
> message
> > > where one of the parts is a complexType and a doc/lit SOAP
> transport
> > can
> > >
> > > create ambiguous situations. The BPEL specification assumes that
> these
> > > ambiguities will be dealt with at the binding layer, perhaps by
> > > forbidding ambiguous message definitions, and are therefore out of
> > scope
> > >
> > > of BPEL.
> > >
> > > 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_workgr
> > > oup.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.
>
>
--
Maciej Szefler <>
