[ebxml-msg] Role/@name, Role/@href, and new requirements.

Hi (long message warning),

Jeff T. explained a little 
more to me why and where the "unique" value requirement
is coming from, and I 
will first explain my understanding of its rationale
and then discuss what we 
might do about it.

The CPPA group had a goal to align BPSS, CPPA, and 
Messaging so that in the
event people used all three together, they work 
together harmoniously.
The addition of a normative appendix tried to explain 
to CPPA users
how CPA information items mapped to Messaging items in the SOAP 
envelope
header blocks as well as for operational parameters (for 
example,
for reliable messaging retry counts...).

Also, text is 
provided for CPPA information items saying what BPSS information
items are 
the sources of data for Messaging items.

So far, only what we 
have
said for Role has created a problem. Apparently we left it 
insufficiently clear
in the Appendix (and text) just what information item is 
used to populate
the Role element in the Messaging header. There are two 
choices that have
been made-- use the value in cppa:Role/@name or 
cppa:Role/@href. My recollection
was that the value should come from 
cppa:Role/@name. Enter into detailed mode.

A BPSS instance can have 
several places that have a role element and the name
attribute can have the 
same value depending on the specific business
process. The nameId value, 
because it is type ID,
must be unique in the document. If we had several 
CollaborationRole elements
in a CPA, that each have their own Role element, 
then the href value could have
different #ID-values to reference the 
different BPSS locations. This feature
supports linking CPA back to BPSS. In 
general, I do not believe we would commonly,
in a CPA, have CollaborationRole 
elements with the same Role/@name values for
the same BinaryCollaboration. If 
this did occur, the lexically later element
would have to be an alternative 
subordinate DeliveryChannel
binding possibly used for failover. At any rate 
it would be an exotic case.

Now it is my understanding that we are to 
consider distinct CollaborationRole
elements in a CPA that pertain to 
different Actions, that have the same
Role/@name values but that have 
different Role/@href values (reflecting
different binary collaborations). In 
this case, the href allows pointing
into the different Role elements in the 
BPSS instance. The issue Hima
raised is this: how upon receiving a Message 
with a Role value, could
I go from that value to the right 
"CollaborationRole" element (or its database
image)? After all, the @name 
value is potentially shared by a first request,
and also a second request in 
a second binary collaboration.
If, however, I had used the href value, I 
could go from the "Role" element
information in the SOAP header, to the right 
place in the choreography.

I agree with Hima that this would be an 
advantage. We could offload maintaining state
within the 
MSH (that I have received the first request in a choreographed chain of 
requests) to
a message value, and let href values for Role track our 
path through choreographies.

However, this functionality really 
represents new functionality for supporting
more complex choreographies, that 
I do not recall being raised as a requirement
for Messaging or BPSS 
alignment. I think that we should proceed by asking:

1. whether Messaging 
wishes to support the ability to map back into constituent 
binary
collaborations in complex choreographies. 2. Messaging wishes to use 
the Role
value to do this, rather than some other more specific backpointer 
value that
more directly accomplishes this.

I personally would prefer 
to see a new (optional) header
element with dedicated semantics
for the 
above problem added to the MessageHeader
that would provide backpointers to 
BPSS (or other)
defined stages (binary collaborations)
in a complex 
choreography. That is, I prefer this if we add new functionality.

 It would be possible to use the Role/@:xlink:href
to get at that 
functionality, but it is a bit of a reach.
I think overloading Role in this 
way also
muddies the semantics of Role, one of whose
original intents was 
to allow two parties to each be buyers
and sellers in a given process 
specification, and yet have
different CPA configurations for those distinct 
roles.

Anyway, I am really persuaded that Hima has raised a new
bit of 
functionality, beyond version 2 in Messaging or CPPA.
I think we should 
consider how best to do it. CPPA can then
take this as an issue, and perhaps 
document both using @xlink:href
and @name as potential values for Roles if 
the overloaded Role
element is the way Messaging wants to handle the 
backpointers
to complex choreographies.

Dale 
Moberg

However,