My first argument is that ExRel's in Webtop are essentially a correlation mechanism. The idea is to say some object, say a Model Element, is related to another object, say a Work Item. The intention is never to understand the underlying data at the other end of a link.
My second argument is that this fits with the Level 1 definition of OSLC where you can link objects simply by using URL's given that each resource/object has a URL.
My third argument is that each side of the ExRel must store the URL of the other side. Now that brings up a question of who stores all these mappings of objects -> related object URL's?
My argument here is that given that we're trying to enable Collaborative ALM here, and avoid brittle point to point integrations, we cannot ask tools to store this data.
The counter argument that just occurred to me when typing this out, is that if each tool were to store objects -> related object URL's mapping then we could have ALM without really using any Jazz services simply relying on REST. That's really a Level 1 kind of idea.
The other way, which I find more appropriate is this. Given that we're speaking of solving ALM, we're definitely talking about more than one tool. So if we're linking objects it must be from the context of a new application (such as RTC/Webtop). Therefore, the objects -> related object URL's mapping storage and maintenance should be done by that application using several Jazz Foundation Services.
We'd obviously store mappings both ways to enable navigation to related objects both ways given that ExRel's are not directional.
