RE: [ebxml-bp] Signal Option

[<martin.me.roberts@bt.com>]

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.

	Thanks

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

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