In-progress Working document - supporting specification development for the evolving versions of CM specifications. This is not an official list of committed items but a live working document to help prioritize and elaborate on the specification efforts.
The purpose of this page is to catalog various specification topics that have arisen and to place on a backlog for consideration in future specification. The list of items will continue to evolve and is not assumed to be in any priority order unless explicitly stated as being.
For additional information on direction for V3 of CM see OSLC CM Architectural Direction V3.
Common case is to have potentially many and possibly large attachments associated with Change Requests
Things to consider:
- Other than the file, what properties exist for this attachment? There are typically some automatically added: creationDate, owner, size, perhaps content-type, id. Others are typically added: name, description. What of these really need to be specified to support scenarios.
- What operations on attachments: view, create, delete, update? It appears create/view are key ones.
- Support for bulk / multiple upload of attachments? Seems like a nice feature but really required?
- Support in existing CM providers: need to consider limitations of mapping to existing models? For example: Attachments are typically considered resources that one of its property is the actual “file”. Attachments have properties that can be modified individually and some that are system defined/computed.
Partial Update (partial)
Proper/full support for partial update (patch)
See Experimental spec
Need for a container for Change Requests, most (if not all) CM providers have a concept of Project. Though their usage and definition differs.
Priority and Severity
Need for a priority and severity properties, with possible set of values. Would be good to have a standard value set that could be mapped to any values provided by clients.
Need for a consumer to execute an action, which triggers a state transition of a Change Request
- There could be the need to record, along with a resource, the tracking of that Resource changes (who, when, what)
- Use for audit trails/history definitions that include what action had been invoked
- May for instance allow to “replay” modifications on a resource
- May be generalized out of CM, for any OSLC resource
- How much detail needs to be exposed on what properties were modified?
- Is this queryable?
Service Provider linking
A way to know “what service provider am I connected to?” or “what service providers are connected to me?”. Also known as “project linking”.
Presentation requirements for resources
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?
Embeddable UI Workspaces
To further support scenarios of UI delegation, there is a need to host a CM provider’s “Change Request Workspace” with things such as: query navigator, toolbar, editor, query results, etc.
Query syntax + certain Change Request properties can support a wider range of scenarios.
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
- VTODO - need to consider aligning with task management tools?
- OpenSocial - need to evolve our delegated UIs to a widget spec when it is available?
- WSDL 2.0 - RESTful service description