HistoryViewLinks to this page 2012 September 18 | 04:48 pm

DRAFT - this scenario is currently under development


This scenario is derived from the CmOfRequirements scenario.

For purposes of conflict detection, a Requirements application may need to query for change requests of varying states such as:

  • assigned or review query
    oslc_cm:inprogress=true OR oslc_cm:fixed=true
  • assigned, review or approved query
    oslc_cm:inprogress=true OR oslc_cm:fixed=true OR oslc_cm:approved=true
  • assigned, review, approved or applied query
    oslc_cm:inprogress=true OR oslc_cm:fixed=true OR oslc_cm:approved=true OR oslc_cm:closed=true
  • assigned or approved query
    oslc_cm:inprogress=true OR oslc_cm:approved=true

These queries are necessary because a requirements application may allow users to propose changes that are conflicting and needs to provide a way for those conflicts to be identified and resolved. Allowing the user to filter on the state of the change request allows for maximum flexibility in determining the scope of proposed changes checked during conflict detection. The user may choose to only look for conflicts in change requests that have been approved, or may decide that it would be better to also check for conflicts with change requests that are currently in progress or under review (fixed).


  • CRs to query


  • no change

Specification needs

Add a new property to the Change Request resource

Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_cm:predicate zero-or-many True String n/a approved
Provides a single property containing all applicable predicates. When retrieving properties of a change request, this new attribute provides the same information as the individual state predicate properties. For example, if oslc_cm:approved=true and oslc_cm:verified=true for a change request, the value of oslc_cm:predicate would be approved and verified.

When used as part of a query with the oslc.where parameter it lets the consumer efficiently filter the query results to find change requests matching more than one of the available predicates.

For example, oslc_cm:predicate in [“inprogress”, “fixed”]



GET /bugs/2314

Accept: application/xml

OSLC-Core-Version: 2.0


HTTP/1.1 200 OK
OSLC-Core-Version: 2.0
Content-Type: application/xml
ETag: "_172190-a702b13"
Content-Length: nnn

<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="http://open-services.net/ns/core#"
    xmlns:oslc_cm="http://open-services.net/ns/cm#" xmlns:ex="http://example.com/bugtracker">

   <oslc_cm:ChangeRequest rdf:about="http://example.com/bugs/2314">
      <rdf:type rdf:resource="http://open-services.net/ns/cm#ChangeRequest" />
       <dcterms:identifier> 00002314 </dcterms:identifier>
       <oslc:shortTitle>Bug 2314</oslc:shortTitle>
       <dcterms:title> Invalid installation instructions </dcterms:title>
       <dcterms:type> Defect </dcterms:type>
       <oslc:instanceShape rdf:resource="http://example.com/shapes/defect" />
          Invalid installation instructions indicating invalid patches to be applied.
       <dcterms:subject> doc </dcterms:subject>
       <dcterms:subject> install </dcterms:subject>
       <dcterms:creator rdf:resource="http://myserver/mycmapp/users/joe" />
       <dcterms:contributor rdf:resource="http://myserver/mycmapp/users/bob" />
       <dcterms:modified> 2008-09-16T08:42:11.265Z </dcterms:modified>
       <dcterms:created> 2008-07-04T11:00:00.000Z </dcterms:created>
       <oslc_cm:status> Fixed </oslc_cm:status>

              <oslc_cm:fixed> true </oslc_cm:fixed>
              <oslc_cm:approved> true </oslc_cm:approved> 
              <oslc_cm:predicate> fixed </oslc_cm:predicate>
              <oslc_cm:predicate> approved </oslc_cm:predicate>

      <oslc:discussedBy rdf:resource="http://example.com/bugs/2314/discussion" />
          rdf:resource="http://myserver/mycmapp/bugs/1235" />
          rdf:resource="http://remoteserver/mycmapp/defects/abc123" />
       <oslc_cm:tracksRequirement rdf:resource="http://myserver/reqtool/req/34ef31af" />
       <oslc_cm:tracksRequirement rdf:resource="http://remoteserver/reqrepo/project1/req456" />
       <!-- Service provider specific properties -->
       <ex:priority> Medium </ex:priority>
       <ex:severity> Normal </ex:severity>


  • Specialized query capabilities - syntax such as “true” in [oslc_cm:fixed, oslc_cm:approved]
  • Adding a simple general “OR” support
    • adds complexity of grouping
    • possible to use a simplified “OR”? doesn’t deal with precendence order or grouping.
  • Run separate queries, client joins - This is the only alternative possible using the existing OSLC-CM 2.0 spec
  • Consider using predicate like oslc_cm:status whose is multi-valued with URIs, like http://oslc.co/ns/cm#statusInprogress
    • Need to confirm “in” allows for values to be resources
    • Need to elaborate whether a new predicate is needed, if we “update” the definition oslc_cm:status
      • Some implementation use this for updating status (state transition)
      • Need more exploration on the impacts of this
      • NOTE: Most agree that is not a good idea, just create new predicate with this definition.
    • Should this be held up with the state transition proposal?

Next steps / Actions:

  • Run with last alternative (a variant of what is proposed) (run with meaning general consensus in the group)
  • Await CmStateTransitions to determine if there is any alignment/impact with proposal


  • ChangeRequest - as-is

Category:Supporting Documents