Re: [ebxml-bp] Reply to Monica: Potential Expressive Shortcomings about Role and current Role convention information

["David RR Webber" <david@drrw.info>]

Dale,

Interesting perambulations!

On the role reversal front - I'm seeing the Context mechanism draft I posted
can help.  It obviously will not solve every possible scenario - but just
being able to now vary things by context should help enormously - since
now it can be made clear that the transactions occurred via a role reversal,
whereas before that was not clear.

BTW - did anyone have any feedback on the context mechanism?
I know Lars is investigating the potential - but I wondered if other people
had found time to review it - and also comment on the CPA linkage?

Thanks, DW.

----- Original Message ----- 
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "Monica J. Martin" <Monica.Martin@Sun.COM>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Thursday, January 08, 2004 11:48 AM
Subject: [ebxml-bp] Reply to Monica: Potential Expressive Shortcomings about
Role and current Role convention information



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.