[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 3/21/2005: isPositiveResponse for DocumentEnvelopeType
In the comments received from Sacha Schlegel, he asked about the isPositiveResponse attribute on the DocumentEnvelopeType. Here is a summary and a proposed recommendation. * isPositiveResponse Summary o What currently exists: + isPositiveResponse exists on the DocumentEnvelopeType although it doesn't have a fixed value. + isPositiveReceipt exists on the ReceiptAcknowledgementType of extension of SignalEnvelopeType although it does have a fixed value ('true'). + isPositiveSignal exists on the ReceiptAcknowledgementExceptionType of extension of SignalEnvelopeType although it does have a fixed value ('false'). + There are no such attributes on Acceptance Acknowledgement. o isPositiveResponse is an indicator for the condition guard for state transitions for Business Success, where the attribute is specified as 'true' or not specified (assumed to be 'true' [1]). This attribute, however, has not historically been used to determine success or failure in the business transaction protocol. o An explanation to why this attribute is as specified is held in Section 4.6.6.3 * Open question: Should the default be specific by indicating: o Default is 'true.' o Default is 'false' and must be explicitly set by the partners to true (to achieve Business Success). o Note: On similar situations, we have selected 'true.' As it relates to the patterns matrices, irrespective of the condition guards, we have chosen 'false' with a recommendation (for intent and guaranteed messaging). * Proposed Solution o NO CHANGE: Do not specify any fixed value. For example, this may be part of a partial response that is handled in the choreography. This is different than our approach in specifying a default on SiganlEnvelopeType. It also supports the adjoining text on condition guard on the state transitions. Note, if this path is taken, the assumption in the preceding bullet [1] is still valid. Please comment on the proposed solution as we will discuss tomorrow. Thanks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]