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


 

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