[ebBP] 2/23/2004: [RSD] Signals and Addl BT Support WI 59

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Discussion|WI59-Signals and Additional BT Support;
Topic|;
Point|Summary proposal;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00168.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00046.html;

mm1@
||Attachment: Signals proposal, Martin Roberts - http://www.oasis-open.org/archives/ebxml-bp/200402/msg00168.html
||Attachment: Signal suggestions, Martin Roberts - http://www.oasis-open.org/archives/ebxml-bp/200402/msg00046.html

Proposal to allow BPSS to offer support for the default set of patterns and allow other external subclasses of patterns such as revocation based negotiations.

Items to consider: 
1. Understand what signals content will be used within a given exchange. 

Roberts Proposal:
Add a set of signal definitions, similar to the document envelope definitions that allows for each of the signals to be defined.  For this there are two options 1) have a discrete set of signals that must be defined 2) have a flexible structure that allows for any type of signal to be attached.  With the first option (discrete set of signal defn) we can neatly hook int the existing patterns, but would find that we could not handle other type of business exchanges outside the existing set.

2. Provide more explicit explanation of when signals would occur and what is allowed to occur.

a) instead of having BusinessTransaction as a fixed structure we introduce a set of subclasses of it that represent the patterns we wish to represent.  These transaction subclasses would define the various parameters required with default values etc and would also describe which signals applied and their appropriate timings.

b) make it absolutely clear which timings are linked with which signal or document.  

3. On RNIF, as a note, last week in joint meeting sessions for EIDX-CompTia-RosettaNet-OAGI, it was acknowledged that RNIF mixes some of the transport level and choreography requirements. Resolution of that has not been formally addressed, to my knowledge. Therefore, we may have to make some decisions to clearly differentiate this.
 
I would encourage comments from the team so we can work to close this issue and consider the schema changes. 
Hima, we welcome your input and comments/suggestions as the signals expert for our team!

Note: This issue relates to WI 31, 59-62, and 65.

Thanks. Monica
=========================================================================================================================
Roberts 16 Feb 2004:
Dear all,
	There were two requests in the area of signals made at the F2F. 
	
	1) It should be possible to show which signal contents are used
with a particular vaerion of the a BPSS.  This leads to some issues if
the signals are related to the transport layer protocol such as
RossettaNet RNIF.  However in most cases it would be useful to point to
the signal definitions as we dod for documents.  I have therefore
introduced a Signals section to allow for this definition see diagram :
signals.gif

	2) To show which signals are to be used within a transaction.
This is important as we have left this information in referenced
documents rather than the schema itself.  I have therefore included a
modified InformationDistribution transaction class that has two extra
components in the RequestingBusinessActivity pointing at the two types
of signals that in turn point ref the Signals defined by item 1 above.
Against the Signal references there is the usual attributes
name,nameID,signalDefinition,signalDeinitionID,isPositiveSignal.  The
last attribute is set to fixed values as appropriate.

	I hope this meets with people approval.  I would like some
response before I go any further with either this or the concrete
pattern classes.

-----Original Message-----
From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com] 
Sent: 13 February 2004 13:55
To: Monica.Martin@Sun.COM; ebxml-bp@lists.oasis-open.org
Subject: [ebxml-bp] Transaction Option


Dear all, 
	attached is a diagram showing how I propose to us ethe Patterns
within the new Schema.

	The key here is the attribute settings of the
RequestingBusinessActivity.  These are shown.

	The RequestingBusinessActivity shown is derived by restriction
which means that no new attributes would be allowed.

	We have two options.  

	1) set them to values as described by the document that
explained the patterns (as shown) Note: use of prohibit for attributes
that do not apply to the pattern - no overide possible.

	2) do a similar defintion as shown except use default values to
show what should be used but allow for overiding.  This would mean that
it would be possible to insist on Non-Repudiation with an
InformationDistribution.

	As the link between the BusinessTransactionAcitivity and the
BusinessTransaction is a IDREF (GUIDREF) there is no change to the
BusinessTransactionActivity for this change.
=========================================================================================================================
@mm1