RE: [ebxml-bp] Re: Updated InformationDistribution, Notification Patterns and Performs (Roles

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

From: Kenji Nagahashi [mailto:nagahashi@us.fujitsu.com] 
Thank you Monica and Dale for quick help!

[omit uml model fidelity issue]

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

Dale> The original problem was an incongruence between performs and the
Notification and InformationExchange using the current conventions.


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.

Dale> I think it is advisable to review a little bit how we got here.
BTs were to be "reusable" by being referencable by any BTA within a
Collaboration (Binary, Multiparty, or the now preferred
BusinessCollaboration). If particular Role values were in the BT, in 1.*
versions it would spoil reusability. So Role values were omitted. To
link Role in a BusinessCollaboration to the BT, in 1.* versions an
attribute mentioned which role was the initiatingRole. This had several
drawbacks. What was the second Role in the BT? In a BinaryCollaboration,
there was only one other Role but in a general BusinessCollaboration
several other roles were defined. Which went with the BT? Also we had a
requirement for Role "re-association". To meet the requirements and
overcome the limitations, we recommissioned Performs to express Role
associations in BTAs, BCs, and CollaborationActivities. 

I agree that there is a slight mismatch of category with Performs as
used within a BTA. If it is bothersome, it seems to me we should restore
Role values in BTs and then have Performs constructs associate with
these BT Role values. For in version 2, we can have reusability and
Roles in a BT.



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

Dale> These conventions are out of synch with a lot of decisions to
always make reference make use of ID values. I am not in favor of doing
this. In fact, if I remember rightly, you were a big supporter of using
ID/IDREF uniformly to do reference. All the well-formedness rules are
expressed in these terms. It would require a lot of special casing for a
small semantic wrinkle. I would much more prefer adding Roles to BT than
going this way.


* Use reserved special role names for referenging BT roles: such as 
"initiator" and "responder"

Dale> If we did this, it would be easier to add Role to BTs, and keep
the existing reference device. Let's not go back to string matches or
use qnames or something else at this point. Wait for a major version
change to re-debate this one.


* discard Performs/@initiatingRoleRef and Performs/@respondingRoleRef

Dale> We can also discard if we add the Role elements to BTs.

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

Dale> Yes, I think it would not be good at this point. I would much
prefer adding Role to BT and just have Performs always associate Roles.
It is then semantically uniform if that is important. We would have to
change a few well-formedness rules that now explain how Performs
references work within a BTA.

Overall, however, I would prefer retaining the the current semantic
polymorphism of Performs and wait until a later version to discuss
further changes.