Review of problem posed by TC on flattening the
current hierarchy:
The most deeply nested elements occur in
CollaborationRole inside PartyInfo.
None of the elements referenced by means of ID
values outside CollaborationRole are here considered for flattening
here.
We currently have
which does not seem too bad until you look under
ServiceBinding where paths expand using
../ServiceBinding/CanSend/ThisPartyActionBinding/
and similar long-winded locutions.
At this time, remember that each CollaborationRole
is limited to one Role and one
ServiceBinding.
What are some options for flattening the hierarchy
under Service Binding?
We could put both the information for Role and the
Service value as children of CollaborationRole, and add a sequence of
(new) ActionBinding elements that organize the information scattered
along the path of
../ServiceBinding/CanSend/ThisPartyActionBinding/
In other words, we could replace the ServiceBinding
element with the Service element, and then add a repeatable
ActionBinding element with the new type
FlatActionBindingType.
The information about whether the ActionBinding is
for sending or receiving is placed in an attribute, @sendOrReceive and
the information from the element OtherPartyActionBinding is placed in
the correlativeBinding attribute (name subject to change, of
course).
These relatively straightforward changes would shave
off about 3 levels of nesting.
Notice that ActionBinding may include an
ActionBinding (which is the current convention for notating “back
channels” on transports. We might investigate a way to replace
this hierarchical nesting by adding a reference to another link for a
business message DeliveryChannel.
In a separate message, I will distribute some notes
about how the schema can be changed to accommodate this new flattened
approach to ServiceBinding while allowing the old nested instances to
be validated also.