(r3) CmArchitecturalDirectionV2 < Main

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>CmHome>CmArchitecturalDirectionV2 (revision 3) (raw view)

---+ OSLC CM Architectural Direction

_Working document - supporting specification development_

The purpose of this page is to collect the architectional 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

<strong>Better handling of differing authenication models<br /></strong>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* <br /> A number of [[ScenariosMylyn][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
      1 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

<strong>Presentation requirements for resources<br /></strong>Some implementations have assumed different models for what HTML should be returned when requested: should it be contained in an IFrame with just dialog for change request viewing and editing? should it be its own page, with application banner and navigation bar?

*Named/Pre-defined Queries* <br />Most, if not all, CM systems have the ability for a user to create a named query to be accessed later for execution. We could fairly rapidly provide at least read-only access to these and execution of queries.

May want to expose this as a query picker/creation tool as done in 1.0 with resources.

*Delegated Service Discovery*
   * better handling of configuration data
   * better scaling
*Alignment of related standards*: 
   * [[http://en.wikipedia.org/wiki/ICalendar#To-do_.28VTODO.29][VTODO]] - need to consider aligning with task management tools?
   * [[http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/OpenSocial-Specification.html][OpenSocial]] - need to evolve our delegated UIs to a widget spec when it is available?
   * [[http://en.wikipedia.org/wiki/Web_Services_Description_Language][WSDL 2.0]] - RESTful service description

Topic revision: r3 - 15 Sep 2010 - 15:15:05 - SteveSpeicher

Main

Webs
Main
Sandbox
TWiki

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