Re: [wsbpel] Issue - 280 - proposal draft for discussion

Danny and I exchanged a few emails on this and he raised the point that the
existing type compatibility checks described in Section 8.4.3 can be done
statically although we don't have language to that effect. The type
compatibility described there is designed to prevent copying incompatible
messages or simple/complex/element values to a message without specifying a
part. In both cases, this can be determined through static analysis. 

The validation proposed for the keepSrcElement differs in that it's runtime
validation so I don't think it as close of a resemblance to Section 8.4.3 as
I had previously asserted.

Perhaps we could update Section 8.4.3 as part of this issue resolution (or
perhaps when we can open new issues) and add the static analysis requirement
there. The only remaining use of the mismatchedAssignmentFailure exception
would be in Section 8.4.2 where an empty string is copied to an L value that
is not an xsd:string or derived type. 

-----Original Message-----
From: Mark Ford [mailto:] 
Sent: Friday, July 28, 2006 9:08 AM
To: 'Alex Yiu'
Cc: 'wsbpeltc'; 'Dieter Koenig1'; 'Thomas Schulze'
Subject: RE: [wsbpel] Issue - 280 - proposal draft for discussion

-1 on keepSrcElement validation

The difference between "real schema validation" and "very basic sanity
check" is an implementation one. It seems to me that if we add support for
this type of check then it should naturally follow that we would add similar
language for complex types. As you and Danny have pointed out, this has been
covered by a previous issue.



-----Original Message-----
From: Alex Yiu [mailto:] 
Sent: Thursday, July 27, 2006 10:16 PM
To: Mark Ford
Cc: 'wsbpeltc'; 'Dieter Koenig1'; 'Thomas Schulze'; Alex Yiu
Subject: Re: [wsbpel] Issue - 280 - proposal draft for discussion


Hi Mark,

You said "I can see how the keepSrcElement validation could be 
interpreted as being in the same spirit as the message variable type 
compatibility checks". You are very right about that point. The nature 
of disallowing copying "Address" element into a variable of "Employee" 
is very similar to that of disallowing copying "AddressMsgType" data 
into a variable of "EmployeeMsgType".

And, these two kinds of checking do not qualify as real schema 
validation. It is just a very basic sanity check to catch a very bad 
problem earlier before the problem blows up in a larger scale. When 
copying the Employee data into a variable of "Employee", if the required 
employee's FirstName attribute is missing, there will be no fault 
triggered. Hence, it does not qualify as schema validation. If validate 
is turned on, then there will be an fault triggered.

BPEL 1.1 assumes all data copy operations will always produce schema 
valid result. That assumption is infeasible to be implemented (i.e. 
compile time cannot enforce it comprehensively; runtime is too 
expensive). And, that also just violates the requirment of a business 
process to incrementally build up a business document. Hence, Issue 169 
was passed to change that assumption.

When we were drafting Issue 157 proposal, type compatibility of copy 
operation for message type was suggested. And, actually, Yaron was not 
that happy about that also. The argument was very similar to the 
argument on this SG topic. Yaron basically suggested, if one wanted to 
make sure the data is valid, use <validate> activity. But, again my 
argument on this topic is: <validate> is a full blown validation and it 
is too costly to use to make sure that this super basic aspect of copy 
operation is right.