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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: ebBP 3/3/2006: Proposal on Condition Guard State Transitions (Section3.6.3)


Today, Dale Moberg, Sally St. Amand, Jamie Clark and I met to discuss a 
tentative proposal for any changes to Section 3.6.3 (and related to 
Figures 14 and 15) in v2.0.2 ebBP technical specification. The original 
related questions from Polaris (in public comment) are provided at the 
end of this email. Note, no diagram changes are proposed for Figure 14 
and 15 as we felt that the existing surrounding descriptive text was 
sufficient, and these proposed changes were value add.

Proposed descriptive changes (Section 3.6.3 only)

Change from:
The enumerated state values represent:
For Success:

    * Success (Both Protocol and Business Success)
    *
    * ProtocolSuccess: Technical Success
    * BusinessSuccess (isPositiveResponse=true or no isPositiveResponse
      attribute): Specific document(s) received.

Change to:
...The enumerated state values represent:
For Success:

    * Success (Both Protocol and Business Success)
    * ProtocolSuccess: Technical Success. For example, acknowledgement
      of receipt of a business document in a Request prior to a timeout.
    * BusinessSuccess (isPositiveResponse=true or no isPositiveResponse
      attribute): Specific document(s) received.

Change from:
...For Failure:

    * Failure (AnyProtocolFailure or BusinessFailure): Specific
      document(s) received.
    * Business Failure (isPositiveResponse=false)
    * AnyProtocolFailure: Technical failure other than those specified.
          o Note: As previously indicated, General Exception is a
            distinct case of the technical failure called
            AnyProtocolFailure....

Change to:
...For Failure:

    * Failure (AnyProtocolFailure or BusinessFailure): For example,
      specific document(s) received.
    * Business Failure (isPositiveResponse=false): Specific business
      document(s) received.
    * AnyProtocolFailure: Technical failure such as those specified or
      any other.
          o Note: As previously indicated, General Exception is a
            distinct case of the technical failure called
            AnyProtocolFailure....

Comments welcome. These and other descriptive, non-substantive changes 
will be discussed in Tuesday's call. Thanks and have a good weekend.

======
reference email
======
Related to Arur's question and Figures 14 and 15, we discussed the state 
transition diagrams in Section 3.6.3 last Tuesday. As planned, everyone 
is welcome to attend a short call tomorrow to discuss Figures 14 and 15.

......The full description of Radha Arur's question and the response can 
be found at:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200602/msg00053.html 


Thanks.

> 5.Distinction between Business message and signal and the relation with
> BSI may be explicitly mentioned.
> mm1: The BSI understands both and their relevance to success or failure
> (whether technical and/or business). If you look at Section 3.6.3 in the
> technical specification (on public web site:
> http://www.oasis-open.org/committees/document.php?document_id=16455&wg_abbrev=ebxml-bp 
>
>
> [pdf in .zip]), it discusses how business messages with an associated
> business document and business signals relate to success or failure. If
> we link these two discussions in the Appendices, Appendix A, will that
> increase your understanding? The specification, appendices, and the
> schema and documentation are used together.
>
> -      A single reference will be easier.







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