The proposed Basic and Bi-Directional profiles currently specify OSLC Query as a MUST in order to get incoming links. In order to include the config profile, we will need to consider how to introduce the OSLC Link Discovery Service. There are two aspects of this Link Discovery Service: 1. How to make the links a server owns discoverable by other servers 2. How to discover incoming links a server doesn't own
ELM tools mostly require a server to contribute their own links through a TRS provider when config enabled. There is a special case for DOORS Next that uses OSLC query for incoming AM links. So it may be necessary to provide an additional ResourceShape constraint to specify which incoming link discovery API should be used to get specific incoming links. Even if this implementation detail is abstracted into the OSLC Link Discovery Service, a mediatory will need to be able to discover how to delegate the request for incoming links.
The proposed Basic and Bi-Directional profiles currently specify OSLC Query as a MUST in order to get incoming links. In order to include the config profile, we will need to consider how to introduce the OSLC Link Discovery Service. There are two aspects of this Link Discovery Service: 1. How to make the links a server owns discoverable by other servers 2. How to discover incoming links a server doesn't own
ELM tools mostly require a server to contribute their own links through a TRS provider when config enabled. There is a special case for DOORS Next that uses OSLC query for incoming AM links. So it may be necessary to provide an additional ResourceShape constraint to specify which incoming link discovery API should be used to get specific incoming links. Even if this implementation detail is abstracted into the OSLC Link Discovery Service, a mediatory will need to be able to discover how to delegate the request for incoming links.