OSLC CM Architectural Direction V2
COMPLETE : These items have been considered "complete" and part of the
CmSpecificationV2. See
CmArchitecturalDirectionV3 for the follow on work.
The purpose of this page is to collect the architectural direction as driven by scenario priorities for the next version of CM specifications (V2). It also contains various 1.0 issues to be addressed in the next version. This follows on to the
CmArchitecturalDirection work done for 1.0.
Items for consideration for 2.0
Better handling of differing authentication models
We've run into some issues when clients don't always know when and how to handle form auth, like when using a batch-mode RESTful interface (feed readers, etc).
Schema A number of
scenarios have shown the need for information for schema of change request resources. Not limited to what is available in XML Schema but addition metadata such as:
- read-only properties
- properties with computed choice lists
- properties that are hidden or not queryable
Reverse service discovery
Since resources are URL-addressable, they often get pasted into tools without going through service discovery.
A possible solution would be to support requesting the service discovery document an the change request resource URI:
- Performing a HEAD operation on the URI could return at least the CR and service document content types, then consumer would know that the URI is an OSLC one.
- Performing a GET operation on the URI with Accept header being x-oslc-cm-service-description+xml would return the service description document, not the chang request
or by embedding the service discovery doc URL in the change request resource definition
Reportable REST
- CM 1.0 provides most of what is needed for response formats and a simple language
- Need to provide schema for potentially 2 purposes:
- Data correlation: reporting tools need to understand data models to merge results
- Query building: in order to build a query (filter) need to know the model. Note: this may be delegated by using approaches similar to those in 1.0, a query builder delegated UI that will produce a URL where the reporting tool can run the created/saved query.
Linking issues:
- need better way to remove the back link in tools that support it
Backlog
These backlog items have
moved to the next iteration of this document for V3