The OSLC AM specification is only one domain specific part of a larger effort. The OSLC Core represents the foundation upon which the domain specific specifications are built upon. Our workgroup must therefore ensure that all our work is compatible with the specifications and best practices of the core workgroup.
This document will be used to monitor and discuss issues with the AM and Core specifications.
The current Core 3.0 Plan can be viewed here. The major milestones are:
- 2H 2012 - Convergence draft, implementation occurring and in finalization
- 1H 2013 - Finalized draft - multiple implementation feedback, interoperable spec
AM Compliance
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 |
MAY |
OSLC service providers MUST provide creation factories to enable resource creation via HTTP POST |
Query Capabilities |
MUST |
OSLC service providers MUST provide query capabilities to enable clients to query for resources no specification on what type of query is supported |
Query Syntax |
MUST |
OSLC query capabilities MUST support the OSLC Core Query Syntax and MAY use other query syntax |
Delegated UI Dialogs |
MUST/MAY |
OSLC Services MUST offer delegated selection UI dialogs and MAY offer delegated creation UI dialogs 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 |
SHOULD |
OSLC Services SHOULD 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 / SHOULD |
OSLC services MUST provide an RDF/XML representation for HTTP GET requests and SHOULD support RDF/XML representations on POST and PUT requests. |
XML Representations |
MAY |
OSLC services MUST provide a XML representation for HTTP GET, POST and PUT requests that conform to the Core Guidelines for XML. |
JSON Representations |
MAY |
OSLC services MUST provide JSON representations for HTTP GET, POST and PUT requests that conform to the Core Guidelines for JSON |
HTML Representations |
SHOULD |
OSLC services SHOULD provide HTML representations for HTTP GET requests |