[ebbp] 9/9/2004: Work Item Discussion Reminder 10 Sept (Note 2 more WI)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Here are a few more in-work items for tomorrow's discussion.  There are 
a few more but I don't want to overload in one meeting :>).

Reminder on call
See: http://www.oasis-open.org/archives/ebxml-bp/200409/msg00056.html

Event Description:
877 204 8750
706 679 5113
passcode 480 627 2648

Piggyback off CPPA call (CPPA call starts at 8 a.m. PDT)

============================================================================
WI-36-39-52-60-Notification of Failure and General Exceptions

Key objectives
   * Separate NOF 'BUSINESS MESSAGE' from general exception 'SIGNAL'.
   * A technical failure can bubble up to a sufficient business state resolution via a signal or a timeout.
   * Specify a NOF could occur only if a timeout occurs for failure to
     receive a requesting or responding business document. In the case
     when there is reliable messaging which shows the receipt of
     request or response,the party should not be capable of sending
     NOF. If for example, a response is sent then a NOF by a responder.
     That is an anomaly; this is to be handled by the business
     agreement (UBAC).
   * Separate and differentiate NOF message, general exception signal (if accepted and developed) and Neg AA. [1]
         o Negative Acceptance Acknowledgment [1]: You recognize you have a problem.
         o NOF: Allows us to clear the slate when the normal exception methods do not apply.
   * Add: Specify a NOF as a new BT pattern.

Mukkamala and Roberts have asked about what should happen if:

   * Extraneous conditions cause the responder or requestor to send
     NOF to invalidate the existing transaction or collaboration (Mukkamala).

       e.g. If a requestor sends a purchase order and responder sends
       an AA, requestor may want to invalidate the current transaction
       because some condition in his system caused the invalidation of
       the PO. This is not part of the reqular business process, however.
  
     Let's discuss this in the context of failed business control that references back to previous guiding principles. [2]

   * Could NOF be used as a general purpose exception handling
     mechanism or do we restrict it to conveying expiration of TTP? (Mukkamala)

   * Cannot send an AA if the appropriate flag isn't set and the pattern is complete (Roberts). Is allowing that via
     an extension of the BT pattern acceptable? Can we send AnyProtocolFailure outside of a transaction?

   * Often, the application/middleware decides whether the message is legible/understandable. Is it also a function of NOF? Question
     relates to EDI documents inside (as an example).

More about NOF and general exception, industry business requirements:
1. RosettaNet: General failure notification applies. This typically is used after a ReceiptAcknowledgement [1]. Implies, for example, something is wrong with order.
2. UBAC: Per Tell, need to provide notification a message was expected not received. This equates to asking for information not
just non-receipt indicator.
3. CPPA: Handling of exceptions are not part of CPPA.
4. Amazon: Has seen different expected and unexpected failures. Don't want to handle unexpected failures; expected failures need to translate to a business result.
Example, expecting a quote, but never received. Another transaction must occur. This doesn't mean abandonment with the
protocol.
5. British Telecom: When a collaboration or collaboration is replayed, which one is failed?  This could be defined or left
to local practice. Determine if exception handling is in another reusable step.  Handle in WI-2 in v3.0.

=============================
[1] This applies to any AA subsequent references - TBD on new name.[1] 
[2] UMM, R10 talks about notifications of failed business control for timeout parameters in several conditions:
a. Not receiving business document in an agreed upon time
b. Not properly receiving the business document in the agreed upon time
c. Not providing verification of receipt in the agreed upon time
d. Not acknowledging acceptance of the business document in the agreed upon time

Reference: ebXML BPSS v1.1, Section 5.14.2.3
isNonRepudiationOfReceiptRequired.
Both partners agree to mutually verify receipt of a requesting business document and that the receipt must be non-
repudiable. A requesting partner must initiate a notification of failure business transaction business (possibly revoking a contractual offer) if a responding partner has not properly delivered signed their receipt. For a further discussion of
nonrepudiation of receipt, see also the ebXML E-Commerce and Simple Negotiation Patterns.

Online references:
1. NOF historical package, 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/8456/signal-historical-discussions-mm1-080204.zip
2. Overview summary, 
http://www.oasis-open.org/archives/ebxml-bp/200408/msg00004.html
3. Also see side notes in isIntelligibleCheckRequired discussion in the 
Kavi email archives starting 6 Sept 2004.

============================================================================

WI-55 (extension) Variables
Proposal is: The Variable specifies a businessDocument and 
businessDocumentIDREF, so that variables can be grouped by business 
document for evaluation and analaysis.  That said, it is important that 
a variable have multiple business document sources, both for business 
document implementations, and the same variable being updated by 
multiple document sources.

E.g
Variable name=OrderState businessDocument=OrderResponse_RosettaNet
Variable name=OrderState businessDocument=OrderResponse_OAG

And

Variable name=OrderState businessDocument=OrderResponse_RosettaNet
Variable name=OrderState 
businessDocument=OrderStatusNotification_RosettaNet

Any business document exchange that meets the definition of the 
referenced business document results in the variable being evaluated and 
added to the result node set.

Yunker's proposal is that the structure be simple:

        < xsd:complexType name =" Variable ">
                < xsd:annotation >
                        < xsd:documentation > Variable content made 
available to condition expressions as a node list containing all 
instances of the variable content (e.g. multiple instance of BTA could 
result in multiple values for variable) </ xsd:documentation >

                </ xsd:annotation >
                < xsd:sequence >
                        < xsd:element ref =" ConditionExpression "/>
                </ xsd:sequence >
                < xsd:attributeGroup ref =" name "/>
                < xsd:attribute name =" businessDocument " type =" 
xsd:anySimpleType " use =" optional "/>
                < xsd:attribute name =" businessDocumentIDREF " type =" 
xsd:IDREF " use =" required "/>
        </ xsd:complexType >

Open item: Determine use cases for business document substitution. Goal 
is to associate the variable with a business document implementation, 
and allow multiple declarations of the variable content.
============================================================================