See also BaselinesInOslc

Comment from DT: This is too coarse.

As a baseline manager, I need to be able to modify the properties of a baseline, and link that baseline to other resources such as test results.

High-ceremony requirements-driven development

Questions:

When the RM role completes a specification and baselines it, how does the QM role address the requirements in that baseline?

One approach is to use contextual URIs:

http://doors.example.com/reqs/r1?baselineURI=http://doors.example.com/baselines/b1

In this case, the client is forming the resource URI from two parts: the base URI of the resource, and the URI of the baseline. The client glues these parts together. This allows for a declarative representation of the "resource-in-context": namely, the base URI of the requirement with a query part describing the baseline of interest.

The client might create a link to this baselined requirement:

<Requirement rdf:about="http://doors.example.com/reqs/r2">
<satisfies rdf:resource="http://doors.example.com/reqs/r1?baselineURI=http://doors.example.com/baselines/b1"/>
</Requirement>

Notice that in doing so, requirement r2 is now fixed to address this requirement r1 in that context. If the context changes, so too might the resolution of r1 in that context (same resource, but perhaps a different state of that resource)

The URI of the requirement in the context of the baseline could also be expressed in another way:

http://doors.example.com/reqs/r1-737272

Where the URI of the requirement is entirely opaque. The provider is responsible for understanding the association between /r1 and /r1-737272.

Use of "out of band" context

This is similar to the design above in which the client presents the context as an HTTP header (the draft spec. also admits that other means are also permitted). It's not so easy to draw a picture of this "resource-in-context" because there is no declarative way to do so. Instead, we have to describe what happens with the various HTTP verbs. Here is GET

GET /reqs/r1
Host: doors.example.com
X-OSLC-Context: http://doors.example.com/baselines/b1
OSLC-Core-Version: 2.0

Will fetch the representation of reqs/r1 in the context of baselines/b1

Another is to use the URIs which are in the snapshot resource (in the "Snapshot-based" specification)

http://doors.example.com/reqs/r1-737

In this case, the client does no gluing together of parts. The snapshot contains the URI of the requirement state, and this URI is used directly:

<Requirement rdf:about="http://doors.example.com/reqs/r2">
<satisfies rdf:resource="http://doors.example.com/reqs/r1-737">
</Requirement>

In this design, the trace relation from r2 is not dependent on the baseline context.

Discussion

In the first design, the baseline (or context) mediates the way in which r2 is associated with interesting states of r1. The baseline context is hard-wired into this association.