Works for me.
Dieter Koenig1 wrote:
> W.r.t. the discussion in the call about reducing the statement to just
> saying BPEL is not fixing any binding bugs, I propose this one:
>
> 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 does not make any assumptions about the WSDL binding.
> Constraints,
> ambiguities, provided or missing capabilities of WSDL bindings are
> out
> of scope of this specification.
>
> Kind Regards
> DK
>
> ----- Forwarded by Dieter Koenig1/Germany/IBM on 02.03.2005 18:30 -----
>
> "Yaron Y. Goland"
> <>
> To
> 02.03.2005 17:29 Satish Thatte
> <>
> cc
> Please respond to wsbpeltc
> ygoland <>
> Subject
> [wsbpel] Issue 154 - Proposal For
> Vote
>
>
>
>
>
>
>
>
>
>
> 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. It is
> at least theoretically possible in some cases for the translation
> between the WSDL binding layer and the WSDL message definition to be
> ambiguous. 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.
>
>
> Satish Thatte wrote:
> > That works for me.
> >
> > -----Original Message-----
> > From: Yaron Y. Goland [mailto:]
> > Sent: Monday, February 28, 2005 10:57 AM
> > To: Satish Thatte
> > Cc: wsbpeltc
> > Subject: Re: [wsbpel] Issue 154 - Proposal For Vote
> >
> > Fine, then let us state that. Let us make it clear in the spec that BPEL
> >
> > will not deal with a message until it has been successfully translated
> > into an abstract message and how that happens is out of scope for the
> > spec. Even a statement like that would resolve the issue.
> >
> > Yaron
> >
> > 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, e-mail:
> For additional commands, e-mail:
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
