OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]