[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] Supporting Signals in BTAs
Monica, Yes - we need that new schema soonest - I especially need to check that we have not broken things that were already working. Thanks, DW ----- Original Message ----- From: "Monica J. Martin" <Monica.Martin@Sun.COM> To: "David RR Webber" <david@drrw.info> Cc: "BPSS ebXML" <ebxml-bp@lists.oasis-open.org> Sent: Sunday, July 11, 2004 12:35 AM Subject: Re: [ebxml-bp] Supporting Signals in BTAs > > > > Webber: I've upgraded the model and added signals - and used the two > > additional fields we discussed adding. > > > > <Signals> > > <Signal name="ReceiptAck" nameID="ReceiptAck2.7" > > specificationLocation="none" specificationID="BPSS-2.7" > > specificationType="" signalPurpose="signal" signalType="success"/> > > <Signal name="AcceptanceAck" nameID="AcceptanceAck2.8" > > specificationLocation="none" specificationID="BPSS-2.8" > > specificationType="" signalPurpose="signal" signalType="success"/> > > > > <Signal name="DefaultContext" nameID="DefaultContext2.6" > > specificationLocation="none" specificationID="BPSS-2.6" > > specificationType="ebContext" signalPurpose="setContext" > > signalType="context"/> > > </Signals> > > mm1: David, the editors' team had some significant discussion around > signals in the F2F last week. We've solidified a Specification element > that we can use in multiple places [1]. The use of a signal purpose > will be deferred until v3.0 as we need more information on its need and > use. The signalType will be added with an enumeration list I believe. > > [1] Schema is being finalized for this and many changes. > > > This all went very smoothly. Notice that the signal is not being > > included in the > > BinaryCollaboration details - as agreed - its an implied interaction > > only - > > but the signal is being written out into the BusinessTransaction > > definition, > > as a RespondingBusinessActivity - > > > > <DocumentEnvelope > > businessDocument="ReceiptAck" > > nameID="ReceiptAck-01" > > isPositiveResponse="false" /> > > > > Since its a signal - the message handling should default to the CPA > > definition > > for signal handling - so that all works too. > > mm1: I don't have all the schema changes but will have a full report on > the progress last week in Monday's call. What I can say, however, is we > are leaning towards as much explicitness as possible for clarity and > implementer ease. I am not certain what you have done here so we can > discuss Monday. A Receipt Ack is not a response David. > > > I think this is complete and works all very nicely - I have no issues > > here to report. > > > > Are there any other questions? If not - I believe we can sign-off on > > the signal > > items and declare victory. > > > > Thanks, DW > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]