[ebxml-bp] Roles and Role Binding in Multi-Party [RSD] WI 13, 28

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Discussion|OASIS.ebBP.Roles;
Topic|;
Point|Roles in multi-party collaboration;

mm1@
Dale,
When we discussed work  item 28 in the F2F, I indicated I would send the 
previous post you made in January 2004. In addition, there was a draft 
multi-party case done by Bob Haugen, although I do not have it. Can you 
please post? Thanks.

Dale Moberg wrote Jan 2004

>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.
>  
>
@mm1