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

["Mark Ford" <mark.ford@active-endpoints.com>]

It's reachable in the current proposal. The first priority is the identical
QName match.
 
-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com] 
Sent: Thursday, July 27, 2006 8:08 PM
To: Mark Ford
Cc: 'Alex Yiu'; 'wsbpeltc'; 'Dieter Koenig1'; 'Thomas Schulze'
Subject: Re: [wsbpel] Issue - 280 - proposal draft for discussion


> 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.

Interesting.  I was about to write that you could just reorder the 
clauses to get the behavior that you're describing, but what I realized 
is that in the current proposal, the 2nd catch in your example is 
unreachable.  Would that be an error?

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 
>
>
>