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

Service Descriptor URI has been stored

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

2. Consumer requests service description doc as application/xml

Service Descriptor URI needs to be discovered

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

Service Provider Catalog URI needs to be discovered

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

Change Request URI has been stored

1. Consumer requests change request as application/x-oslc-cm-change-request+xml TBD

2. Consumer requests change request as application/xml TBD

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

Other URIs have been stored

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

1. query same URI can be used and the older syntax with oslc_cm. prefix can be used by 2.0 provider to indicate 1.0 consumer

2. factory same URI can be used, content type are based on 1.0 (application/x-oslc-cm-*) and the OSLC-Version header is omitted

3. dialogs same URI can be used, consumer defines protocol to use based on older definitions #oslc-postMessage-1.0 etc

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)

References

• W3C Architecture of WWW