Reply to Monica: Potential Expressive Shortcomings about Role and current Role convention information

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

Monica comments:

[Dale Moberg] Premise: ... it is not clear how we track the association
of occupants 
with Roles through a collaboration.

The BPSS associates the roles of the binary collaboration within the 
collaboration or business transaction activity where the roles become 
explicit. In addition,
in the collaboration activity, the inner collaboration and its roles are

bound to the parent collaboration [1]. Roles are also assigned to the 
initiatingRole and respondingRole [2]. I agree this could be more 
expressive and flexibility/adaptability should be improved, although we 
do have underlying semantics from which to work.


Response:

By "expressive shortcomings" I meant to indicate that some information
items need to be 
added to the schema to allow BPSS instances to express specific
connections between occupants 
of a Role in one BP segment with the occupant of a Role in another BP
segment. The occupants
are mainly what other ebXML specs refer to as parties (Though we only
care about their number
and abstract identity, not what their partyIDs are. It would break our
abstraction level 
to model these occupants much more specifically. Maybe some type or
legal constraint
information could be pasted on the abstract participants,like Anders has
suggested, but
nothing more deployment specific than that. Leave that to UBAC and/or
CPPA and similar efforts.)

The parts of the specification you mention lay down _general_ semantics
for specific constructs,
that announce conventions about connections of Roles. These general
connections are not explicitly
represented by elements/attributes in BPSS instances. Also, these
connections 
obviously do not vary from instance to instance, they are always
stipulated for
the relevant situations. [I actually think that if we introduce explicit
occupants,
and association assertions between them and a role, then we might be
able to remove
the restriction of [1]. I am not certain that any inviolable business
requirement is captured
by [1] but maybe there is one. ]

I think we will not be able to lay down general conventions to deal with
use cases such as
role reversal. Role reversal is a specific use case for instances and is
not found generally.
That is why I think we need specific support for expressing these
connections within instances.
We have about reached the end of what can be said generally about what
role goes with what. 
If we do recognize that there are constraints on role occupancy that are
not generally present,
then we should bite the bullet now for version 2, and introduce the
needed constructs. I think
a lot of discussion remains for what constructs to introduce, where they
go, and how to allow
reusability. However, I am trying to see whether we can reach initial
consensus that an addition
is needed, and the basic requirements for those additions. 

I thought about trying to contine introducing general conventions, like
the ones that we have in
your refs [1] and [2] and how these would map role occupants in a
multiparty to role occupants
in binary collaborations, or how to do role reversal, and IMO, using
general role occupant constraints
just don't have the expressive flexibility that is needed. 

So I think I disagree with you somewhat that we have all the underlying
semantics in place. I think we
need an extension. We should also have a suggested an xslt for embedding
1.x instances within 2.x instances
for support continuity.