OSLC Requirements Management 2.0 Specification
2.0 Convergence draft This current draft is in convergence phase, gathering community feedback and review prior to entering finalization stages.
Introduction
This family of documents defines the Open Services for Lifecycle Collaboration Requirements Management and Definition specification, also known as OSLC RM. These documents collectively define the OSLC RM 2.0 specification, which is part of the OSLC group of specifications. This specification supports key REST APIs for software Requirements Management systems. OSLC RM 2.0 takes an open, loosely coupled approach to specific lifecycle integration scenarios. The scenarios and this V2.0 specification were created by the OSLC RM Working Group. More information on the principles underlying OSLC and RM in particular can be found on the main OSLC site and the home page of the RM topic.
Terminology
Requirement Resource - Some statement of need.
Service Provider - an implementation of the OSLC Requirements Management specification.
Service Consumer - an implementation of a client which consume resource models provided by a service provider.
Notation and Conventions
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
RFC2119. Domain name examples use
RFC2606.
Base Requirements
Compliance
This specification is based on
OSLC Core Specification? . OSLC RM consumers and service providers
MUST be compliant with both the core specification and this RM specification, and SHOULD follow all the guidelines and recommendations in both these specifications.
The following table summarizes the requirements from OSLC Core Specification as well as some additional specific to RM. Note that this specification further restricts some of the requirements for OSLC Core Specification. See further sections in this specification or the OSLC Core Specification to get further details on each of these requirements.
Requirement |
Level |
Meaning |
Unknown properties and content |
MAY / MUST |
OSLC services MAY ignore unknown content and OSLC clients MUST preserve unknown content |
Resource Operations |
MUST |
OSLC service MUST support resource operations via standard HTTP operations |
Resource Paging |
MAY |
OSLC services MAY provide paging for resources but only when specifically requested by client |
Partial Resource Representations |
MAY / MUST |
OSLC services MUST support request for a subset of a resource's properties via the oslc.properties URL parameter retrieval via HTTP GET and MAY support via HTTP PUT |
Partial Update |
MAY |
OSLC services MAY support partial update of resources using patch semantics |
Service Provider Resources |
MAY / MUST |
OSLC service providers MAY provide a Service Provider Catalog and MUST provide a Service Provider resource |
Creation Factories |
MUST |
OSLC service providers MUST provide creation factories to enable resource creation via HTTP POST |
Query Capabilities |
SHOULD |
OSLC service providers SHOULD provide query capabilities to enable clients to query for resources |
Query Syntax |
MUST |
OSLC query capabilities MUST support the OSLC Core Query Syntax and MAY use other query syntax |
Delegated UI Dialogs |
MUST |
OSLC Services MUST offer delegated UI dialogs (creation and selections) specified via service provider resource |
UI Preview |
SHOULD |
OSLC Services SHOULD offer UI previews for resources that may be referenced by other resources |
HTTP Basic Authentication |
MAY |
OSLC Services MAY support Basic Auth and should do so only over HTTPS |
OAuth Authentication |
MAY |
OSLC Services MAY support OAuth and can indicate the required OAuth URLs via the service provider resource |
Error Responses |
MAY |
OSLC Services MAY provide error responses using Core defined error formats |
RDF/XML Representations |
MUST |
OSLC services MUST provide an RDF/XML representation for HTTP GET, POST and PUT requests. |
HTML Representations |
SHOULD |
OSLC services SHOULD provide HTML representations for HTTP GET requests |
Specification Versioning
See
OSLC Core Specification Versioning section? .
Service providers that support the resource formats and services in this specification
MUST use HTTP response header of
OSLC-Core-Version
with a value of
2.0
. Consumers
MAY request formats and services defined in this document by providing a HTTP request header of
OSLC-Core-Version
with a value of
2.0
. See section below on Version Compatibility with OSLC RM 1.0 Specifications.
Namespaces
In addition to the namespace URIs and namespace prefixes
oslc
,
rdf
,
dcterms
and
foaf
defined in the
OSLC Core specification? , OSLC RM defines the namespace URI of
http://open-services.net/ns/rm#
with a namespace prefix of
oslc_rm
This specification also uses these namespace prefix definitions:
- oslc_cm :
http://open-services.net/ns/cm#
(Reference: OSLC CM)
- oslc_qm :
http://open-services.net/ns/qm#
(Reference: OSLC QM)
Resource Formats
In addition to the requirements for
OSLC Core Resource Formats section? , this section outlines further refinements and restrictions.
For HTTP GET requests on all OSLC RM and OSLC Core defined resource types,
- RM Providers MUST provide RDF/XML representations.
- RM Consumers requesting RDF/XML SHOULD be prepared for any valid RDF/XML document. RM.
- RM Providers SHOULD support an [X]HTML representation and a user interface (UI) preview as defined by UI Preview Guidance?
For HTTP PUT/POST request formats for RM resources:
- RM Providers MUST accept RDF/XML representations. RM Providers accepting RDF/XML SHOULD be prepared for any valid RDF/XML document.
For HTTP GET response formats for Query requests,
- RM Providers MUST provide RDF/XML representations.
Content Negotiation
OSLC Core Guidance clearly points to RDF representations (and specifically RDF/XML) as a convention that all OSLC Provider implementations minimally provide and accept. OSLC RM Provider implementations are strongly encouraged to adopt this convention and MAY offer other representation formats at their discretion.
RDF/XML Representation - identified by the
application/rdf+xml
content type. No additional guidance is given. The OSLC Core describes an algorithm for generating consistent formats that are used as examples only.
Authentication
See
OSLC Core Authentication section? . OSLC RM puts no additional constraints on authentication.
Error Responses
See
OSLC Core Error Responses section? . OSLC RM puts no additional constraints on error responses.
Pagination
OSLC RM service providers
SHOULD support pagination of query results and
MAY support pagination of a single resource's properties as defined by the OSLC Core Specification.
Requesting and Updating Properties
Requesting a Subset of Properties
A client
MAY request a subset of a resource's properties as well as properties from a referenced resource. In order to support this behavior a service provider
MUST support the
oslc.properties
and
oslc.prefix
URL parameter on a HTTP GET request on individual resource request or a collection of resources by query. If the
oslc.properties
parameter is omitted on the request, then all resource properties
MUST be provided in the response.
Updating a Subset of Properties
A client
MAY request that a subset of a resource's properties be updated by identifying those properties to be modified using the
oslc.properties
URL parameter on a HTTP PUT request.
If the parameter
oslc.properties
contains a valid resource property on the request that is not provided in the content, the server
MUST set the resource's property to a null or empty value. If the parameter
oslc.properties
contains an invalid resource property, then a
409 Conflict
MUST be returned.
Updating Multi-Valued Properties
For multi-valued properties that contain a large number of values, it may be difficult and inefficient to add or remove property values. OSLC RM Service Providers
SHOULD provide support for a partial update of the multi-valued properties as defined by
OSLC Core Partial Update? .
RM Resource Definitions
Property value types that are not defined in the following sections, are defined in
OSLC Core - Defining OSLC Properties?
Resource Requirement
The Requirement resource may have the following set of properties. Requirement resource properties are not limited to the ones defined in this specification, service providers may provide additional properties. It is recommended that any additional properties exist in their own unique namespace and not use the namespaces defined in these specifications.
- Name:
Requirement
- Type URI
http://open-services.net/ns/rm#Requirement
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Core: Common Properties |
dcterms:title |
exactly-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Title (reference: Dublin Core) of the resource represented as rich text in XHTML content. SHOULD include only content that is valid inside an XHTML <span> element. |
dcterms:description |
zero-or-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <div> element. |
dcterms:identifier |
zero-or-one |
True |
String |
n/a |
n/a |
An identifier for a resource. This identifier may be unique with a scope that is defined by the RM provider. Assigned by the service provider when a resource is created. Not intended for end-user display. |
oslc:shortTitle |
zero-or-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Short name identifying a resource, often used as an abbreviated identifier for presentation to end-users. SHOULD include only content that is valid inside an XHTML <span> element. |
dcterms:subject |
zero-or-many |
False |
String |
n/a |
n/a |
Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. |
dcterms:creator |
zero-or-many |
unspecified |
Resource |
Either |
foaf:Person |
Creator of resource (reference: Dublin Core). |
dcterms:contributor |
zero-or-many |
unspecified |
Resource |
Either |
foaf:Person |
Contributor to resource (reference: Dublin Core). |
dcterms:created |
zero-or-one |
True |
DateTime |
n/a |
n/a |
Timestamp of resource creation (reference: Dublin Core). |
dcterms:modified |
zero-or-one |
True |
DateTime |
n/a |
n/a |
Timestamp last latest resource modification (reference: Dublin Core). |
rdf:type |
zero-or-many |
unspecified |
Resource |
Reference |
n/a |
The resource type URIs. |
oslc:serviceProvider |
zero-or-many |
unspecified |
Resource |
Reference |
oslc:ServiceProvider |
The scope of a resource is a URI for the resource's OSLC Service Provider. |
oslc:instanceShape |
zero-or-one |
unspecified |
Resource |
Reference |
oslc:ResourceShape |
Resource Shape that provides hints as to resource property value-types and allowed values. |
oslc:discussion |
zero-or-one |
unspecified |
Resource |
Reference |
oslc:Discussion |
A sequence of notes and discussions about this requirement. |
Prefixed Name |
Occurs |
Read-only |
Value-type |
Represen-tation |
Range |
Description |
Relationship properties: This grouping of properties are used to identify relationships between resources managed by other OSLC Service Providers |
oslc_rm:elaboratedBy |
zero-or-more |
False |
Resource |
Reference |
unspecified |
Resource, such as a model element, which elaborates this requirement. |
oslc_rm:specifiedBy |
zero-or-more |
False |
Resource |
Reference |
unspecified |
Resource, such as a model element, which specifies this requirement. |
oslc_rm:affectedBy |
zero-or-more |
False |
Resource |
Reference |
unspecified |
Requirement is affected by a resource, such as defect or issue. |
oslc_rm:trackedBy |
zero-or-more |
False |
Resource |
Reference |
unspecified |
Resource, such as a change request, which track this requirement. |
oslc_rm:implementedBy |
zero-or-more |
False |
Resource |
Reference |
unspecified |
Resource, such as a change request, which implements this requirement. |
oslc_rm:validatedBy |
zero-or-more |
False |
Resource |
Reference |
unspecified |
Resource, such as a test case, which validates this requirement. |
Resource RequirementCollection
The
RequirementCollection? resource may have the following set of properties.
RequirementCollection? resource properties are not limited to the ones defined in this specification, service providers may provide additional properties. It is recommended that any additional properties exist in their own unique namespace and not use the namespaces defined in these specifications.
- Name:
RequirementCollection
- Type URI
http://open-services.net/ns/rm#RequirementCollection
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Core: Common Properties |
dcterms:title |
exactly-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Title (reference: Dublin Core) of the resource represented as rich text in XHTML content. SHOULD include only content that is valid inside an XHTML <span> element. |
dcterms:description |
zero-or-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Descriptive text (reference: Dublin Core) about resource represented as rich text in XHTML content. SHOULD include only content that is valid and suitable inside an XHTML <div> element. |
dcterms:identifier |
zero-or-one |
True |
String |
n/a |
n/a |
An identifier for a resource. This identifier may be unique with a scope that is defined by the RM provider. Assigned by the service provider when a resource is created. Not intended for end-user display. |
oslc:shortTitle |
zero-or-one |
unspecified |
XMLLiteral |
n/a |
n/a |
Short name identifying a resource, often used as an abbreviated identifier for presentation to end-users. SHOULD include only content that is valid inside an XHTML <span> element. |
dcterms:subject |
zero-or-many |
False |
String |
n/a |
n/a |
Tag or keyword for a resource. Each occurrence of a dcterms:subject property denotes an additional tag for the resource. |
dcterms:creator |
zero-or-many |
unspecified |
Resource |
Either |
foaf:Person |
Creator of resource (reference: Dublin Core). |
dcterms:contributor |
zero-or-many |
unspecified |
Resource |
Either |
foaf:Person |
Contributor to resource (reference: Dublin Core). |
dcterms:created |
zero-or-one |
True |
DateTime |
n/a |
n/a |
Timestamp of resource creation (reference: Dublin Core). |
dcterms:modified |
zero-or-one |
True |
DateTime |
n/a |
n/a |
Timestamp last latest resource modification (reference: Dublin Core). |
rdf:type |
zero-or-many |
unspecified |
Resource |
Reference |
n/a |
The resource type URIs. |
oslc:serviceProvider |
zero-or-many |
unspecified |
Resource |
Reference |
oslc:ServiceProvider |
The scope of a resource is a URI for the resource's OSLC Service Provider. |
oslc:instanceShape |
zero-or-one |
unspecified |
Resource |
Reference |
oslc:ResourceShape |
Resource Shape that provides hints as to resource property value-types and allowed values. |
oslc:discussion |
zero-or-more |
unspecified |
Resource |
Reference |
oslc:Discussion |
A sequence of notes and discussions about this requirement collection. |
Prefixed Name |
Occurs |
Read-only |
Value-type |
Represen-tation |
Range |
Description |
OSLC RM: Start of additional properties |
oslc_rm:uses |
zero-or-more |
unspecified |
Resource |
Reference |
n/a |
A collection uses a requirement - the assocaited requirement is in the requirement collection. |
Prefixed Name |
Occurs |
Read-only |
Value-type |
Represen-tation |
Range |
Description |
Relationship properties: This grouping of properties are used to identify relationships between resources managed by other OSLC Service Providers |
oslc_rm:elaboratedBy |
zero-or-more |
False |
Resource |
Reference |
n/a |
Resource which elaborates this requirement collection. |
oslc_rm:specifiedBy |
zero-or-more |
False |
Resource |
Reference |
n/a |
Resource which specifies this requirement collection. |
oslc_rm:affectedBy |
zero-or-more |
False |
Resource |
Reference |
oslc_cm:ChangeRequest |
Requirement Collection is affected by a reported defect. |
oslc_rm:trackedBy |
zero-or-more |
False |
Resource |
Reference |
oslc_cm:ChangeRequest |
Change requests which track this requirement collection. |
oslc_rm:implementedBy |
zero-or-more |
False |
Resource |
Reference |
oslc_cm:ChangeRequest |
Implemented by associated ChangeRequest? . |
oslc_rm:validatedBy |
zero-or-more |
False |
Resource |
Reference |
QM resource |
QM resource which validates this requirement collection. |
RM Service Provider Capabilities
Resource Shapes
OSLC RM services providers
SHOULD support
Resource Shapes? as defined in
OSLC Core Specification?
Service Provider Resources
OSLC RM service providers
MUST provide a
Service Provider Resource? that can be retrieved at a implementation dependent URI.
OSLC RM service providers
MAY provide a
Service Provider Catalog Resource? that can be retrieved at a implementation dependent URI.
OSLC RM service providers
MUST provide a
oslc:serviceProvider
property for their defined resources that will be the URI to a
Service Provider Resource? .
OSLC RM service providers
MUST supply a value of
http://open-services.net/ns/rm#
for the property
oslc:domain
on either
oslc:ServiceProvider
or
oslc:ServiceProviderCatalog
resources.
Creation Factories
OSLC RM service providers
MUST support
Creation Factories? and list them in the Service Provider Resource as defined by OSLC Core
Query Capabilities
OSLC RM service providers
SHOULD support the
Query Capabilities? as defined by OSLC Core.
The Query Capability
MUST support these parameters:
-
oslc.where
-
oslc.select
-
oslc.properties
-
oslc.prefix
Delegated UIs
OSLC RM service providers
MUST support the selection and creation of resources by delegated web-based user interface dialogs
Delegated UIs? as defined by OSLC Core.
OSLC RM service providers
MAY support the pre-filling of creation dialogs based on the definition at
Delegated UIs? .
Usage Identifiers
OSLC RM service provider can identify the usage of various services with additional property values for the
OSLC Core? defined
oslc:usage
property on
oslc:Dialog
,
CreationFactory
and
QueryCapability
. The
oslc:usage
property value of
http://open-services.net/ns/core#default
will be used to designate the default or primary service to be used by consumers when multiple entries are found.
The additional property values for
oslc:usage
are:
-
http://open-services.net/ns/rm#ian
- primarily used by ...
Version Compatibility with 1.0 Specifications
The goal is to provide a smooth transition to 2.0 for both Consumers and Providers. This section will clarify the usage of 1.0 media types so that Providers can support both 1.0 and 2.0 Consumers when HTTP requests are made for a resource with the same URI.
Network addressable resource URIs used for 1.0 resources for these types: Requirement, RequirementCollection, ServiceDescriptor and ServiceProviderCatalog, should not have to change. Consumers who support both 1.0 and 2.0, should only preserve these resource URIs. When a Provider starts to serve 2.0 resource formats, for instance the ServiceProvider resource, it is recommended to update its locally stored or cached information about the contents of the ServiceProvider resource as the URIs to various capabilities may have changed (query, delegated UIs, factories, etc).
Media Types
To identify a format of RDF/XML, the media type used for RM resource representations SHOULD be
application/rdf+xml
. The usage of the OSLC RM 1.0 defined media types of
application/x-oslc-rm-requirement-1.0+xml
,
application/x-oslc-rm-requirement-collection-1.0+xml
,
application/x-oslc-rm-service-description-1.0+xml
and
application/x-oslc-disc-service-provider-catalog+xml
is being depreciated.
Requesting formats
RM 1.0 consumers wanting to request 1.0 resource formats will not need to change if they used 1.0 defined media types (
application/x-oslc-rm*
), see OSLC-RM 1.0. RM 2.0 consumers should use media types as defined in this specification for requests, excluding the OSLC RM 1.0 specific media types (
application/x-oslc-rm*
). RM consumers supporting both 1.0 and 2.0, should request request both 1.0 and 2.0 media types on HTTP GET requests as usually done with HTTP request parameter
Accept
giving appropriate quality (See HTTP Accept) weighting to help distinguish their preferred content.
For additional guidance, a RM 2.0 consumer or provider MAY reference the
OSLC-Core-Version
HTTP header with a value of
2.0
.
Appendix A: Samples
See
RmSpecificationV2Samples?
Appendix B: Resource Shapes
See
RmSpecificationV2Shapes?
Appendix C: Notices and References
Authors and Contact Information
- AndyBerner? (IBM)
- ScottBosworth? (IBM)
- JimConallen? (IBM)
- GeorgeDeCandio? (IBM)
- JeremyDick? (Integrate)
- BrendaEllis? (Northrop Grumman)
- RainerE? (Siemens)
- IanGreen? (IBM; OSLC RM Lead)
- AndreasKeis? (EADS)
- NicholasKruk? (IBM)
- ChrisMcGraw? (IBM)
- PaulMcMahan? (IBM)
- DevangParikh? (IBM)
- VishyRamaswamy? (IBM)
- RenRenganathan? (Citigroup)
- DavidRuiz? (Ravenflow)
- MatthewStone? (Stoneworks)
- DominicTulley? (IBM)
- RandyVogel? (Accenture)
- SimonWills? (Integrate)
Reporting Issues on the Specification
The working group participants who author and maintain this working draft specification, monitor a distribution list where issues or questions can be raised, see
Requirements Management Mailing List
Also the issues found with this specification and their resolution can be found at
RmSpecV2Issues?
Intellectual Property Covenant
The members of the Working Group (or as appropriate, their employers) have documented a Patent Non-Assertion Covenant for implementations of the CM 2.0 Specification, as described in the open-services.net
Terms of Use. Details of the Covenant may be found
here? .
References