This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
RmHome
>
RmMeetings
>
RmBaseliningDiscussion
(08 Aug 2011,
IanGreen
)
(raw view)
---+++ See also BaselinesInOslc Comment from DT: This is too coarse. <blockquote> 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. </blockquote> ---+ 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"><br /> <satisfies rdf:resource="http://doors.example.com/reqs/r1?baselineURI=http://doors.example.com/baselines/b1"/><br /></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<br />Host: doors.example.com<br />X-OSLC-Context: http://doors.example.com/baselines/b1<br />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"><br /> <satisfies rdf:resource="http://doors.example.com/reqs/r1-737"><br /> </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.
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r2 - 08 Aug 2011 - 12:08:16 -
IanGreen
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback