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

[Alex Yiu <alex.yiu@oracle.com>]

Hi Mark, Danny and others,

Yes, I agree that the current message type checking in section 8.4.3 can be done by static analysis, while this SG-based element name checking needs to be done in runtime.

The spirit is the same. Mechansim involved can be different.

Given that we have already put in a considerable amount of effort to make a single-part WSDL (of element) message-type-based variable look like a element-based variable. This additional SG-based check will make that effort into a full circle.

And, I just want to make it clear that this SG-based element checking was never mentioned in any TC discussion. This is a brand new idea suggested by Dieter during the course of Issue 280 discussion, which I think it makes sense to add. If peope thought it has been mentioned in any past issue discussion before, please quote the email link.


Thanks!


Regards,
Alex Yiu


Mark Ford wrote:

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:mark.ford@active-endpoints.com] 
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:alex.yiu@oracle.com] 
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.

  

why we don't enforce any other type compatibility during assigns?

    

During Issue 157, I was thinking to do some validation for simple type 
data. So that, an runtime error can be signaled, if one attempt to 
assign a string value "ABC" to an integer variable.

This design direction was borrowed again from XPath 2.0. It has two 
different operators: "cast as" and "treat as". The former is for simple 
type. The latter is for complex type. If there is something wrong in 
data values, the former will signal a runtime error, while the latter 
would not. This is yet another pragmatic design pattern in a standard 
specification to weigh in the cost and benefit.

Similarly, Yaron had some push back on this design. And, after 
consideration, if the error is detected by <assign><copy> layer as 
mismatchedAssignmentFault, then the underlying XML data model 
implemention behind those BPEL variable will signal that error. If XML 
certain data model implementation is used, the BPEL implementation will 
be no choice but to propagate that error. That error may be covered by 
"subLanguageExecutionFault" or other standard fault and details on when 
the error would occur can be considered outside the scope of BPEL spec. 
Hence, I did not pursue further.


Hope this explains the rationale well.


Thanks!



Regards,
Alex Yiu



Mark Ford wrote:

  

I don't like the idea of mandatory schema validation for the keepSrcElement
    

case. I don't recall any other part of the spec where we require validation
unless it is explicitly indicated with the <assign>'s validate attribute or
the <validate> activity. Section 8.4.3 describes type compatibility but only
with respect to assigning to and from message variables. I can see how the
  

keepSrcElement validation could be interpreted as being in the same spirit
    

as the message variable type compatibility checks but if that's the case
then would people wonder why we don't enforce any other type compatibility
during assigns? 
  

Mark Ford wrote:

  

I don't like the idea of mandatory schema validation for the keepSrcElement
case. I don't recall any other part of the spec where we require validation
unless it is explicitly indicated with the <assign>'s validate attribute or
the <validate> activity. Section 8.4.3 describes type compatibility but
    

only
  

with respect to assigning to and from message variables. I can see how the
keepSrcElement validation could be interpreted as being in the same spirit
as the message variable type compatibility checks but if that's the case
then would people wonder why we don't enforce any other type compatibility
during assigns? 

The proposed changes to the fault matching rules in Section 12.5 look good.
My previous concerns regarding the determination of the fault data type
    

have
  

been addressed. 

One thing I found missing was that the matching priority only considers the
order of the <catch> elements when there are multiple compatible matches. I
was expecting to see some consideration of the SG hierarchy.

For example:

Given the following SG hierarchy:

E1
|--E2
  |--E3
     |--E4

...and the following fault handlers:

<faultHandlers>
  <catch faultElement="E1"> ... </catch>
  <catch faultElement="E2"> ... </catch>
</faultHandlers>

If the runtime data is E4 then E1 and E2 are both compatible but E1 would
    

be
  

selected since it appears first. I would have thought that E2 would have
been selected since it is closer in the SG hierarchy to E4.

-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com] 
Sent: Wednesday, July 26, 2006 3:40 AM
To: wsbpeltc
Cc: Alex Yiu; 'Dieter Koenig1'; Thomas Schulze
Subject: [wsbpel] Issue - 280 - proposal draft for discussion


Hi all,

Last week, Dieter, Thomas and I have worked together to provide a new 
proposal draft for Issue 280.

Please take a look!
(Since this draft is sent out to the public less than 12 hrs before the 
conf call, I guess voting will be up for in the conf call next week)


Thanks!


Regards,
Alex Yiu



 

    

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php