[no subject]

There was some confusion with us in the link between the ebMS
and the patterns,  could one message contain both the receipt and the
document?  If so were they in a particular order?  Very confusing.  What
ever we do we must make it simple an fool proof.

Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki



-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: 29 December 2003 17:04
To: Boonserm (Serm) Kulvatunyou; ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp] [12/12/03]: BPSS Signals


Serm,

+1.

It's crazy to have three or four messages exchanged here.

The answer would appear to be - that one message can
indicate multiple things - I would suggest:

1) Acceptance Acknowledgement is also implied Receipt Ack
    so no need to send RecAck if you send an AccAck (timing
    is something you need to determine -if your business process
    may mean a time-out could occur between receipt and
    calculating the acceptance - then you will need to send both).

2) Negative Receipt and Acceptence Exception - clearly these
    are different - so you need to be able to handle both these
    conditions - and you should only get one of these at a time.

DW.

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


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