Title: Re: [wsbpel] Issue - 280 - proposal draft for discussion
Just to clarify that this element-SG checking was not never discussed
in the TC until 280.
And, messageType checking during copy is already passed and in the spec
text already.
(as quoted by Mark)
And, I am not talking about simple type checking here.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
Alex-
-1
I understand your rationale now, as I did then. We held that vote, and
this rationale lost. Your proposal, in effect, reopens those arguments.
Alex Yiu wrote:
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:]
>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
