RE: [ebxml-bp] Decision vs Fork

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

JJ,
  Can you clarify something.  If you have any of these with a transaction that does not exit to another fork, join or decision does this effectively give you the possibility to return to the same fork, decision etc
 
  What does an OR fork mean?
 
  How does the isConcurrent affect these constructs?
 
Martin

	-----Original Message----- 
	From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com] 
	Sent: Fri 06/02/2004 14:44 
	To: ebxml-bp@lists.oasis-open.org 
	Cc: 
	Subject: [ebxml-bp] Decision vs Fork
	
	

	Hi:
	
	I wanted to add from our discussion yesterday that a:
	a) a fork means that several path are possible but we don't when and
	which paths will be active
	b) an XOR fork means that as soon as one of these path are active, all
	the others become disabled. However, all were possible to start with
	c) a decision differs from a fork in the sense that a decision selects
	only one possible path, the other one is automatically disabled. An XOR
	fork could be designed to operate like a decision, but a decision cannot
	amount to an XOR fork.
	
	Hope this clarifies a bit what we said,
	
	JJ-
	
	-----Original Message-----
	From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com]
	Sent: Friday, February 06, 2004 4:52 AM
	To: ebxml-bp@lists.oasis-open.org
	Subject: [ebxml-bp] Signals suggestions
	
	As part if the F2F we have discussed the signals issues. Two in
	particular.
	
	The first is how does anyone know which signals content will be used
	within a given exchange.  The second was a request from Dale Moberg to
	have a more explicit explanation of when signals would occur and what is
	allowed to occur.
	
	The solution to the first is simple:  We 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.
	
	This links into the next problem which was how to make it absolutely
	clear when they would be sent.  My suggestion is that we do two things:
	
	1) 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.
	
	2) make it absolutely clear which timings are linked with which signal
	or document. 
	
	With these two modifications we could allow BPSS to offer support for
	the default set of patterns, but also we could allow other external
	subclasses of patterns to be developed to cover off use cases such as
	those that Anders Tell has requested (revocation based negotiations).
	As these would not be directly in BPSS, people such as the UBAC team
	could trial their use before getting them adopted into later BPSS
	versions.
	
	
	
	There is a catch though.  For the first time the schema of BPSS would be
	designed to be extended.  This would require the use of schema extension
	models such as the Venetian Blind (noah's ark) in a similar manner to
	the OAG.  Personally I use this technique in my Business documents and
	have been grateful for the flexibilty it offers.  However, it will mean
	a change to the way the CPA can manipulate timings etc, which leads me
	to think that this is also linked with the debate on the external
	context device.
	
	
	Again take care.
	
	Martin