Jacques,
I just can't believe that! There's always a way to refactor the XML to make it serve the needs.
Actually I welcome the challenge here - as I sense the real need is to grapple with the CPA and all its nuances - to bring the right mechanisms into play to enable people to easily compartmentalize the various aspects of the solution set - so they can all work together coherently.
I did have significant success for the NIH project in breaking down the CPA into templatable parts that can be assembled into a coherent whole - based on business drivers - such as "high security", "confirmed delivery", and so on - that equate then to pre-set characteristics that are known to work and provide the functionality desired. Pim I know has also been working on this.
Now - WRT the multi-hop - I see no issue with creating a new component that specifically addresses those needs - and then integrating this as another referencable part to a CPA.
And WRT long lists of URLs and such - the XML should handle that easily - afterall lookups are what XPath loves to provide. Similarly the CPA's themselves. The ebMS components have to store these and look them up based on CPAid values in the message enveloping anyway - to determine actions and configuration details.
Now with the agents acting as relay points - you will need proxy CPAs that determine actions - but again - this seems what the multi-hop extensions to the current CPA can cover off here.
So overall I'd be in favour of clarifying the modular approach to the current CPA - here's the current parts and how they relate. Then introducing whatever new part is needed for multi-hop (of course optional) as an additional component.
Once we've broken the problem down in this way - I believe finding the solution(s) should be much clearer.
Thanks, DW