Issue - 11 - Editing 9.3.1

["Yaron Goland" <ygoland@bea.com>]

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 also
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? =)

<<attachment: winmail.dat>>