RE: [ebxml-bp] Re: ebBP 2/22/2005: Any Protocol Failure Question: section 4.6.8.1 and 4.8.3

["Yunker, John" <yunker@amazon.com>]

Let's look at the business case.

AnyProtocolFailure is designed to allow the protocol to catch and orchestrate behavior when the protocol fails.

Any protocol failure includes general exception.  Any un-orchestrated general exception should result in NOF (or other agreed setting aside of the transaction)

John

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@sun.com] 
Sent: Wednesday, March 09, 2005 5:00 AM
To: ebXML BP
Cc: Dale Moberg; himagiri@sybase.com; steve.c >> Steve Capell
Subject: [ebxml-bp] Re: ebBP 2/22/2005: Any Protocol Failure Question: section 4.6.8.1 and 4.8.3


After yesterday's discussion, we still have a partially open question 
related to: Is a general exception actually an AnyProtocolFailure? If 
so, other than a technical failure, are there other details to discuss 
on state transition. Thanks.

> mm1: 2/22/2005: Today, we discussed this question briefly. How do we
> separate or compare the AnyProtocolFailure to general exception. There 
> are actually > 1 questions here. So I will attempt to articulate:
>
>    * Any protocol failure is one of the enumeration values of the
>      ConditionGuardValue list that can apply to a substate (status)
>      visibility or to condition guard. See Sections 4.6.8.1 and 4.8.3,
>      that specify guards on transitions.
>    * General exception is defined but is not part of the BT patterns
>      defined (as it is unplanned). See Section 4.8.2.3.
>
> Therefore, is general exception an 'AnyProtocolFailure' other than the
> other types specified? I ask this question because the use of the 
> general exception is not articulated as a guard. ....
>
> So we have to answer:
>
>    * How do GeneralException and AnyProtocolFailure relate if at all?
>      One is in the defined transition guards (the latter) and the other
>      is completely unplanned. ......
>    * After answering above question, what schema changes may be
>      required. Tech spec language will follow.