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