How does a CM provider resolve a concept URI plus configuration context?

[David Honey <david.honey@uk.ibm.com>]

The specification at https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt.html#context
describes how a concept URI plus a configuration context (section 6) can
be used to determine the state of a version resource associated with the
GC context. But how does a CM provider or GC provider resolve it?

For example, imagine the following contribution
hierarchy:
    GC1
        GC2
           
LC1
           
LC2
        LC3
           
LC4

Given a URI of some concept
resource CR and a configuration context CT, how does a tool determine which
configuration applies?
The GC provider will know the
component associated with GC1, and the component associated with GC2,
However, it won't know which,
if any, of the configurations LC1, LC2, LC3 or LC4 are relevant for the
concept resource.

Which of the following is the
intended/proposed resolution:

1. Each consuming tool asks the GC provider for a contribution hierachy (either explicitly, or through repeated GETs), and then calls each contributor to attempt to determine the configuration for the concept resource.
2. Each consuming tool asks the GC provider to resolve the concept URI plus GC URI. The GC provider then determines the contribution hierarchy and then calls each contributor to attempt to determine the configuration for the concept resource.

If #2, shouldn't
this service be described in the specification?
The advantage of doing so is
that there is a single implementation that each tool can leverage, and
this ensures consistency of contribution ordering.

Is the suggested algorithm
that a call is made to each CM provider to see if it can find a version
for the concept resource plus local configuration URI?
For example, assuming the ordering
of contributions is shown in the tree, perform the GETs on each configuration
in LC1, LC2, LC3, and LC4 until the first one indicates it exists?
A concern is that having to
ask potentially of the CM providers each time will be expensive and might
take significant time.
What if a concept resource
is only applicable to a tool T, and tool T is the CM provider for LC3 and
LC4.
Can the algorithm omit asking
LC1 and LC2 because the concept resource does not apply to their associated
tools?

What if LC1 returns a result
that no version of CR is used - a 404 NOT_FOUND response?
Does this mean the search returns
with that result?
Or does it mean that LC2 must
be asked next?

The issue here is that some
CM tools might not know whether the concept CR applies to a configuration.
For example, Rational's Configuration Management application will always
return a result for any CR, that result being either <null> (meaning
no version selected), or the URI of a specific version. Consider that LC1
and LC2 are configurations managed by that Configuration Management application.
The results from all four configurations might be as follows:

Configuration	Response
LC1	OK, <null>
LC2	OK, <null>
LC3	404 NOT_FOUND
LC4	OK, version1uri

What is the expected result
of the resolution algorithm?

1. <null>?
2. version1uri?

For #1, the caller cannot distinguish
between the following use cases:

1. The concept resource does not apply to the Rational Configuration Management application configuration.
2. The concept resource does apply to the Rational Configuration Management application configuration, but no version is eligible or suitable for that configuration.

Best regards,
David.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU