Re: [ebxml-bp] [12/12/03]: BPSS Signals

["Boonserm \(Serm\) Kulvatunyou" <serm@nist.gov>]

Monica,

I think the fact is that the more profiles expected in a spec, the more mesh
of incompatibility one allows. If you profile such parameter, two systems in
fact can functionally interoperate, instead they are not. My concern is
whether it is worthwhile to create a potential incompatibility for such
parameter. When a parameter is added to a spec and that parameter is not
independent of others the number of test cases required will grow by the
multiplicative factor. In this case, it at least dependent on the RecAck and
AccAck parameters (2 x 2 tests are associated with these two), so roughly
speaking we are adding another 4 tests (not yet thinking about how the
RecAck and AccAck are dependent on other params). This adds more time and
cost to write and execute tests. It has more ramification in interop test.
Again, is it worthed.

My 2 cents,
- serm

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Monday, December 29, 2003 9:54 AM
Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals


> Boonserm (Serm) Kulvatunyou wrote:
>
> >I think these additional sementics poise to two potential issues.
> >1) It will be more difficult to do conformance and interop testing.
> >2) It adds more complexity without unique functionality to the spec in
which
> >cost vs. value need to be considered. We should not forget about the
> >simplicity side of the spec for SME sakes.
> >
> >- serm
> >
> mm1: Serm: 1) Could not profiling be used to test the more common cases
> like the IIC created a profile for core or base functionality, then
> allow other profiles for the more complex or edge cases. The
> combinations may enable more user flexibility, and profiles could allow
> that flexibility to be tested for that particular community. 2) If
> additional attributes or definition was allowed to enable such
> capabilities and the capabilities were optional, would this
> be a reasonable tradeoff for any SME user?
>
> What are your thoughts? Thanks.
>
> >
> >
> >----- Original Message ----- 
> >From: "Monica J. Martin" <Monica.Martin@Sun.COM>
> >To: <Lars.Abrell@teliasonera.com>
> >Cc: <ebxml-bp@lists.oasis-open.org>
> >Sent: Sunday, December 14, 2003 2:06 PM
> >Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals
> >
> >
> >
> >
> >>The discussion can begin on this during the learning session on Monday.
> >>
> >>I will add this as a potential work item to our list as well.
> >>
> >>Thanks, Lars.
> >>
> >>Lars.Abrell@teliasonera.com wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>As input to the learning session coming Monday about BPSS signals I
want
> >>>
> >>>
> >to share with you some thoughts and experiences we have found trying to
use
> >the BPSS spec.
> >
> >
> >>>We want to be informed of receipt errors discovered by our trading
> >>>
> >>>
> >partner validating business Requests coming from us. We also want to be
> >informed of acceptance errors discovered by our trading partner. We
> >therefore enable both the (negative) Receipt Exception signal and the
> >(negative) Acceptance Exception signal by setting a value > 0 in the
> >timeToAcknowledgeReceipt and the timeToAcknowledgeAcceptance attributes.
> >
> >
> >>>But at the same time with the current BPSS spec we are also enabling
the
> >>>
> >>>
> >(positive) Receipt Acknowledgment signal and the (positive) Acceptance
> >Acknowledgment signal. This means that we receive these positive signals,
> >from our trading partner when he did *not* discover any receipt or
> >acceptance errors, prior to receiving a substantive business Response (in
> >response to our business Request) soon after.
> >
> >
> >>>For a business transaction activity that includes both a Requesting
> >>>
> >>>
> >business activity (ReqBA) and a Responding business activity (RespBA),
and
> >when the business document in the Request is correct in every sense, this
> >means that we have to receive three messages - two Signals and one
> >substantive Response. In some situations, for example in business
> >transaction activities with short response time ("timeToPerform") this
seems
> >to be too many "unnecessary" messages. We think that if we receive a
> >(positive or negative) substantive business Response document it also
tells
> >us that there were no (Receipt or Acceptance) errors of any kind in our
> >business Request document.
> >
> >
> >>>When there are no errors, we should receive only the (positive or
> >>>
> >>>
> >negative) substantive Response and no positive Receipt or Acceptance
> >Acknowledgment signals, even if we do receive the negative Receipt and/or
> >Acceptance Exception signals when something is in error.
> >
> >
> >>>We believe that if we receive a business Response in response to the
> >>>
> >>>
> >business Request, it will imply both a positive Receipt Acknowledgment
> >signal and a positive Acceptance Acknowledgment signal. This means that
if
> >the BPSS spec is changed according to our proposal, it will be possible
to,
> >in some situations, "save" (not to send) two signal messages.
> >
> >
> >>>Of course the positive signals may still be needed in other situations.
> >>>
> >>>We want the BPSS specification to allow us separately for the
Requesting
> >>>
> >>>
> >business activity (ReqBA) express that we only want to be informed about
> >receipt or acceptance errors discovered by our trading partner. And we
want
> >to be able to express that we *not* want a positive signal, when he did
> >*not* discover any receipt or acceptance errors.
> >
> >
> >>>We want the possibility of separately telling our trading partner that
we
> >>>
> >>>
> >want to be informed, by a negative signal when he discovers any errors
> >because we think that is something different from telling our trading
> >partner that we want him to inform us, by a positive signal, if he did
*not*
> >find any errors.
> >
> >
> >>>Even though we sometimes not want the positive Receipt Acknowledgment
> >>>
> >>>
> >signal and the positive Acceptance Acknowledgment signal for the
Requesting
> >business activity (ReqBA) we still might want to enable these signals for
> >the Responding business activity (RespBA). Otherwise our trading partner
> >might have to wait until the time-out of the receipts until he can
proceed
> >the state of the collaboration because he will never know otherwise if
the
> >response was not processed properly. If not, there will always be the
> >ambiguity if our receiving system had been jammed and never got to send
that
> >it did effectively process the response message.
> >
> >
> >>>* Lars.Abrell@TeliaSonera.com * +46 (0) 705 619080
> >>>* Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
>
>