OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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