Re: [ebxml-bp] Re: Updated InformationDistribution, NotificationPatterns and Performs (Roles

[Kenji Nagahashi <nagahashi@us.fujitsu.com>]

Thank you Monica and Dale for quick help!

I found the diagram quite familiar as RosettaNet has been using the 
diagram for years...

Seeing the diagram, I still find nothing wrong with current BT schema, 
except for possible confusion of a "Activity" concept.

If what we want here is word-by-word adoption of UML activity diagram 
representation for transaction patterns, it would be the right thing to 
let BTs always have two Activities. But I'm not sure if this adoption is 
the good thing, since the activity diagram requires redundant 
description. It would be good for explaining the semantics of patterns, 
but not for use of pattern (as BPSS is meant for).

<Dale>
> The other Role is the initiator of the RespondingActivity. Because each
> of the RequestingBusinessActivity and RespondingBusinessActivity has a
> unique nameID value to refer to, that permits each Role to be uniquely
> associated with an activity. 
</Dale>

After reading this, I (finally) realized that focus of the discussion is 
the role-binding between BC roles and BT roles (is it right? how dumb am I).

In current draft specification, BTA/Performs points to 
RequestingBusinessActivity or RespondingBusinessActivity! (Sorry I 
didn't know that). I see semantic anomaly here. I propose that Perform 
should not directly refer to Activity in BT; it should always refer to 
BT Roles and Activities should get associated with the external role 
though those BT roles. If Perform always binds role to role, 
specification would be simpler and more consistent.

Of course this approach has a problem: two roles in BT are implicit and 
doesn't have ID to refer to! So I'd propose the following solution:

* make Performs/@currentRoleRef and Performs/@performRoleRef string type 
attributes
* and let them refer to Roles by Role/@name instead of Role/@nameID
* Use reserved special role names for referenging BT roles: such as 
"initiator" and "responder"
* discard Performs/@initiatingRoleRef and Performs/@respondingRoleRef

Is this bad because inconsistent with the policy of using @nameID for 
referencing?

Regards
Kenji