Define Scenarios and Approach to Resource Definition Extensions in V2

Working Document: Not a specification

Purpose of this page is to gather requirements and issues with evolving CM resource definitions and formats to V2.

Scenarios

1.0 Consumer with upgraded 2.0 Provider

These are the scenarios where a 1.0 consumer may have made requests in this way:

Service Descriptor URI has been stored (is known)

1. Consumer requests service description doc as application/x-oslc-cm-service-description+xml

When: Provider doesn't locate request version header and also recognizes1.0 defined content-type

Response: Service descriptor 1.0 definition with content-type application/x-oslc-cm-service-description+xml

2. Consumer requests service description doc as application/xml

When: Provider doesn't locate request version header

Response: Service descriptor 1.0 definition with content-type application/xml

Service Provider Catalog URI has been stored (is known)

1. Consumer requests service provider catalog as application/x-oslc-disc-service-provider-catalog+xml

When: Provider doesn't locate request version header and also recognizes 1.0 content-type

Response: Service Provider Catalog 1.0 definition with content-type application/x-oslc-disc-service-provider-catalog+xml

Change Request URI has been stored (is known)

1. Consumer requests change request as application/x-oslc-cm-change-request+xml (same applies for +json requests)

When: Provider doesn't locate request version header and also recognizes 1.0 content-type

Response: Change request 1.0 definition with content-type application/x-cm-change-request+xml

2. Consumer requests change request as application/xml

When: Provider doesn't locate request version header

Response: Change request 1.0 definition with content-type application/xml

3. Consumer requests change request as application/rdf+xml

When: Provider doesn't locate request version header

Response: Change request 1.0 definition with content-type application/rdf+xml

Other URIs have been stored

Note it is recommended not to store these but instead cache them. Store service descriptor URI and check periodically for updated content (new URIs)

1. query same URI

When: using older syntax with oslc_cm. prefix indicates 1.0 consumer, with desired content types

Response: Query results following rules of 1.0 query capability, with requested content type

2. factory same URI

When: using content types are based on 1.0 (application/x-oslc-cm-*) and the OSLC-Version header is omitted

Response: use 1.0 based content types and rules for resource creation

3. dialogs same URI

When: consumer defines protocol to use based on older definitions #oslc-postMessage-1.0 etc

Response: use provider implementation following 1.0 delegated creation/selection rules

2.0 Consumer accessing a 1.0 Provider

Service Descriptor URI has been stored

1. TBD

Service Descriptor URI needs to be discovered

1. TBD

Requested formats

1. TBD

Misc

- link types - there shouldn't be an issue, since 1.0 formats will be returned to 1.0 consumers (utilizing @collref) and 2.0 formats will be returned to 2.0 requesters (utilizing @rdf:resource)

Future scenarios

2.0 Consumer accessing a 3.0 Provider

TBD

1.0 Consumer accessing a 3.0 Provider

TBD

Generic OSLC Core Consumer accessing a 2.0 Provider

TBD

References

• W3C Architecture of WWW