OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Some options for flattening CPPs and CPAs, an initial proposal.


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.

 

 

 

 

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]