Re: [wsbpel] Issue - 11 - Editing 9.3.1

["Danny van der Rijn" <dannyv@tibco.com>]

+1.  but i respectfully request that you open another issue number for this.
i think this is the third bona fide important issue that is known as issue
#11.

> P.S. Did you really read this far? =)

of course i did.  it was spellbinding.

----- Original Message ----- 
From: "Yaron Goland" <ygoland@bea.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Friday, August 08, 2003 3:33 PM
Subject: [wsbpel] Issue - 11 - Editing 9.3.1


> Executive Summary:
>
> This e-mail identifies two separate problems with the BPEL
> specification.
>
> The first problem is that the language in section 9.3.1 makes it
> effectively impossible to ever copy any data into a message type variable
> from any source other than another message type variable of identical
type.
> This was never intended and the language needs to be amended so as to
match
> the original intent.
>
> The second problem is that even if section 9.3.1 is fixed so that it
> says what the authors originally intended this would still prohibit a
> situation in which one could copy XML from a source whose schema is <ANY>
to
> a destination whose schema is anything other than <ANY>. This is because
> 9.3.1 requires that the schema of a source either be identical to or a
> subtype of the destination's schema.
>
> This e-mail therefore proposes that:
> * The rules in 9.3.1 be altered so that the validation
> requirement read that the XML instance from the source must be valid
against
> the schema of the destination regardless of the source's schema.
> * It be legal to copy entire messages of different types so
> long as the message structure and parts names of the source match the
> message structure and part names of the destination and the XML instance
> associated with each part in the source matches the schema in the matching
> part in the destination.
> * A new fault be introduced that would be thrown if a copy
> is attempted where the source's XML instance is not valid against the
> destination's schema.
> * The validation rules described in the three previous
> points be allowed for use with input/output variables for
> receive/invoke/reply. That is, one can submit an input/output variable
whose
> message type is not identical to the message type of the associated
> operation so long as the type of the variable submitted is valid as
defined
> in the previous three points.
>
> Long Winded Version:
>
> Let's imagine a programmer has a variable that contains a WSDL message
that
> contains three parts, each part with some schema definition. We will call
> the variable REAL.
>
> The programmer wants to build up the value in REAL but needs to do so
> incrementally. The most natural thing for the programmer to do would be to
> create a variable called DUMMY which also has 3 parts but whose schema
> definition is 'ANY' for each part. Once the programmer is ready to send
off
> a message the programmer could submit DUMMY as the input variable to an
> invoke. So long as DUMMY has the same number of parts with the same part
> names as expected by the invoke and so long as the contents of each part
> match against the schema for the outgoing message then everything should
be
> fine. If there is a mismatch then a fault would be thrown.
>
> However this behavior is illegal in BPEL. I have to admit that I can't
find
> the exact language in the BPEL spec which requires that input (and output)
> variables MUST be of the same message type as the message being sent or
> received but this is the intended BPEL requirement. That is why there is
no
> fault for 'your input variable doesn't match the message schema for the
> identified operation'. Such a fault can never occur because static
analysis
> would detect that the mismatch and reject the BPEL before it ever got a
> chance to run.
>
> But our intrepid programmer is not so easily bowed. He decides that
instead
> of submitting DUMMY directly to the invoke he will instead issue a COPY of
> DUMMY to REAL and then submit REAL to the invoke. However this plan is als
o
> illegal in BPEL. Section 9.3.1, point 1 explicitly states that one cannot
do
> an assignment between two variables with different WSDL message types,
even
> if the syntaxes are compatible.
>
> But wait, our programmer isn't defeated quit yet, what he will do is issue
> three copies, one for each part in DUMMY and copy each part individually
to
> REAL. There are a number of reasons to believe that even this is illegal.
>
> Reason #1 - The language in point 1 of section 9.3.1 provides a blanket
ban
> on copying from one message type to another. No exceptions are made for
> cases where one is just copying a particular part of a message.
>
> Reason #2 - The language in point 3 of section 9.3.1 does allow for values
> from different schemas to be copied to each other but only if the source's
> schema is a subtype of the destination's schema. In this case the source's
> schema is <ANY> which is clearly not a sub-type of the destination's
schema.
>
> Ahh, but our industrious programmer is still not quite beaten. He figures
> that what he can do is use a copy where the from spec is "expression" and
> then use the getVariableData function in an XPATH to copy the values from
> DUMMY and then point at REAL. Do this three times and he is done.
>
> Unfortunately, this is also illegal. Point #2 of section 9.3.1 explicitly
> forbids a situation in which a from/to is a WSDL message type and the
other
> is not.
>
> In fact, given the language as it now exists in section 9.3.1 it looks
like
> it is impossible to ever legally copy any value into a WSDL message type
> variable unless the source is another variable of exactly the same WSDL
> message type.
>
> Obviously this wasn't the intent and the language clearly needs to be
fixed.
> What was intended however is that one could only copy data from a source
to
> a destination if the source and destination's schemas are identical or if
> the source's schema is a sub-type of the destination's schema. There was
> never any intention that it would prevent legitimate behavior like copying
a
> subsection of one value into another where the schemas exactly matched.
> Unfortunately the language in 9.3.1 does not actually say any of this and
so
> needs to be modified.
>
> Even if 9.3.1 is fixed to match its intent and it is legal to copy any XML
> from any source to any destination so long as the schemas either match or
> the source is a sub-type of the destination our poor programmer is still
in
> trouble. He cannot submit DUMMY directly to the invoke because its message
> type doesn't match. He cannot copy content from one part of DUMMY to its
> matching part in REAL because the schema for the DUMMY part is <ANY> which
> clearly isn't a sub-type of anything. About the only trick he might be
able
> to pull off is to use expression and getVariableData to pull content out
of
> DUMMY and put it into REAL but that will only work if the BPEL engine
isn't
> sophisticated enough to associate schema with data retrieved through an
> XPATH function. In theory the BPEL engine could still detect the schema
> mismatch and reject the copy.
>
> In other words, you really can't get there from here.
>
> I would propose that the way forward is to introduce implicit casting into
> BPEL. Section 9.3.1 should be re-written to have a two level matching
> restriction.
>
> If the destination is an entire WSDL message (e.g. there is no part
> specified) then the source MUST have the same message structure and part
> names (but not necessarily message type) as the destination.
>
> In all cases when moving XML from source to destination the XML from the
> source MUST be validated against the schema of the destination. If the
> source's XML does validate against the destination's schema, regardless of
> the schema of the source, then the copy is allowed.
>
> I would also propose that we apply these same rules for
receive/invoke/reply
> so that both input and output variables that have a matching message
> structure but different schemas can be used so long as schema validation
> works as described above.
>
> In this way the programmer could submit DUMMY directly to the invoke and
so
> long as the parts and schemas validate against the operation's message
> definition then all is fine. If not, we will introduce a new exception
that
> will then be thrown.
>
> Yaron
>
> P.S. Did you really read this far? =)
>


----------------------------------------------------------------------------
----


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org