[OASIS Issue Tracker] (OSLCCORE-5) What are the OSLC 2.0 / 3.0 Compatibility Requirements

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59679#comment-59679 ] 

James Amsden commented on OSLCCORE-5:
-------------------------------------

High level summary of potential changes to Core 3.0 in order to provide compatibility with 2.0:

1. Authentication - Minor changes: ensure HTTP challenge/response is sufficient for OAuth2, other OAuthConfiguration URIs would be covered under discovery below.

2. Resource Discovery and Representations - Significant change: provide two discovery mechanisms in Core 3.0, one that supports more static discovery using Service Provider Catalog compatible with Core 2.0 and another that supports more dynamic, incremental discovery based on LDP and link headers.

3. Resource Operations (Create, Read, Update, Partial Update, Delete) - Some minor updates to address If-Match header on update, partial update and paging.

4. Delegated UI (for creation, preview and selection) - Minor changes - just ensure Dialog resource is consistent with v2.0. Discovery is handled above. Compact link representation and preview requires more study, but should be easy enough.

5. Query Service - Minor change: Core 3.0 may want to include a MAY conformance criteria referencing OSLC 2.0 Query Service as this is some that client and servers currently use. Other query services such as SPARQL may also be provided.

6. Resource Paging - Should reference OSLC Core 2.0 paging as current 2.0 clients will be using this. This is a candidate for deprecation in the future if LDP supports paging.

7. Resource Constraints (Resource Shapes) - Minor change to use ldp:constrainedBy and say that servers MAY use ResourceShapes to define the constraints.

8. Tracked Resource Set - No change: Not an issue for OSLC Core 3.0 as clients and servers can continue to use OSLC 2.0 TRS.

9. Attachments - No change: Not defined in OSLC 2.0 core, so there are no compatibility issues.

10. Actions - No change: Not an issue for OSLC Core 3.0 as clients and servers can continue to use OSLC 2.0 Actions.

11. Automation - No change: Not an issue for OSLC Core 3.0 as this is a domain specification and clients and servers can continue to use OSLC 2.0 Automation.

> What are the OSLC 2.0 / 3.0 Compatibility Requirements
> ------------------------------------------------------
>
>                 Key: OSLCCORE-5
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-5
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Task
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> Are clients and servers expected to reflectively support both versions with no compatibility implied between them? This appears to be the current compatibility approach and guidance.
> What is the recommendation for OSLC 2.0 capabilities not yet included in OSLC 3.0 - avoid them, implement them on a 3.0 server? Do we even know if that’s possible? Use a 2.0/3.0 hybrid server? Will vendors be willing to implement that? Is it practical?
> Given a recommendation, what are the possible incompatibilities that might need to be discovered and addressed in the current OSLC 3.0 specifications? 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)