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.

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:
    1. Data correlation: reporting tools need to understand data models to merge results
    2. 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

Topic revision: r4 - 07 Dec 2010 - 21:14:40 - SteveSpeicher
 
This site is powered by the TWiki collaboration platform 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