RE: Comment

[Bob Haugen <linkage@interaccess.com>]

Scott Hinkelman wrote:
>I understand your desire to align to the Composite in order to generically
>make available consistent recursion. I might be a little concerned on 
>loosing a lower level of detail like outlined in your narrative. 

I don't understand. The level of detail in the narrative can
remain the same, by composing the optional features
as required - or so I think.  What am I missing?

>Upon looking at this further, I would think that by nature
>the StepDefinitions are in fact a sequence within the BPD, 

If  they had OrderingRules, they could be sequenced.
But I am proposing to move the OrderingRules, so that any 
Composite could have sequenced members.

>so perhaps add <<ordered sequence>> to the by-value aggregation 
>from BPD to StepDefinition.

Sequence rules are not always the best way to transition from
one step to another (using step in a generic sense).

>From what I gather from the narrative,some Steps would be
>BusinessTransactions (by definition are B2B message-based) 
>and some may not be "Buyer wants to recieve products". 

Correct.

>So, when we define a BPD is appears we are also implicitly, via
>another not-obvious-specialization of Step at the level of
>BusinessTransaction, taking into account
>business economic events that are not realized within the 
>B2B space through messages.

You lost me there.  As far as I know, ebXML is only considering
economic events that are realized thru B2B messages.  (Of course
lots of other economic events may occur, but they are beyond the
scope of ebXML as far as I know...)

>This is what motivated me to say StepDefinition should not have a
>BusinessTransactionConstraint, as I viewed the BusinessTransactionConstraint >conditions for the in-B2B message space Step specialization. 

If you are considering the current V2.0 metamodel, I would agree.
I was referring to a much-simplified BusinessProcessDefinition
hierarchy which did not have a BusinessTransaction class, where
business transaction logic was invoked by adding a 
BusinessTransactionConstraint feature to whatever 
BusinessProcessComponent needed it.

>My thought is that at the most gross level you do A, and if
>it worked you do B, and if it worked, you do C (A,B,C may 
>or may not all be realized in the B2B message space), and 
>this is the intention for BPD aggregating Steps.

That is one possibility.  But then how do you handle optional
steps like product returns?  And that is only one example
where a straight sequence may not be the best model -
maybe a state transition model would be better in some cases.
("OrderingRule" was kept deliberately abstract to accomodate
any notion of transitioning.)

>Further thinking: perhaps a Contract actually results at the Step level 
>on BusinessTransaction.........
>(don't I have a non-B2B-message-based Contract for say "Buyer wants to
>recieve Products" ? Hmmmm

I missed your point again, sorry...

>I see the BusinessTransaction as the specialialization of a Step 
>in the B2B space intended to be a unit of electronic business. 

That is certainly the intention of the current metamodel, which
has the flaws noted by Karsten and others.  But, the Composite
pattern could be used and still have a specialized BusinessTransaction
class instead of the optional BusinessTransactionConstraint feature
at the top abstract class level - in other words, the Composite
pattern and the optional feature idea are separable proposals.

>I get all of the narrative about PartnerRole, Initiator, etc.
>It appears there could be value in specializing PartnerRole with 
>Initiator and Responder................

Something like that would make sense. I'm not sure PartnerRole 
specialization is the way to do it. The Edifecs/RosettaNet metamodel 
designates Requesting and Responding Business Activity stereotypes,
and Request/Response as a Business Collaboration Pattern.

>The whole thing then overlaps with TRP at Information Exchange. 
>To TRP, this is called a MessageSet. [Side note is that by my