[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=59678#comment-59678 ] 

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

I'll try to summarize where we are on this issue, and where we might want to consider going. We can queue this topic for discussion next meeting, and I have an agenda item with the OSLC-SC to get their input and feedback.

First let's list the goals of the OSLC Core 3.0:
  1. Support interoperability and integration of client and server lifecycle applications
  2. Reduce the implementation burden for clients and servers
  3. Provide a stable, long-lived platform for developing OSLC domain specifications 
  4. ...

Compatibility requirements that support those goals:
  1. OSLC 2.0 client can access OSLC 3.0 server without change
  2. OSLC 3.0 client can have limited discoverable access OSLC 2.0 server
That is, OSLC 2.0 and 3.0 clients should interoperate with OSLC 2.0 and 2.0 servers where the discovered capabilities overlap.

Implications of these compatibility requirements:
  1. All Core 2.0 capabilities must be in scope (query, paging, resource shapes, TRS, Actions
  2. Anything that is a MAY or SHOULD in Core 2.0 is a candidate for inclusion in 3.0 
  3. Any MAY or SHOULD OSLC Core 2.0 capability that is not included in or does not overlap with the a OSLC Core 3.0 capability can be left out of OSLC Core 3.0 and clients and servers can continue to use the open-services.net specification of the capability. In some cases, OSLC Core 3.0 may which to include MAY and SHOULD references to relevant sections in OSLC Core 2.0.
  4. Any MAY or SHOULD OSLC Core 2.0 capability that is included in or does overlap with the corresponding OSLC Core 3.0 capability SHOULD be supported by OSLC Core 3.0 in a backward compatible way. OSLC
    4.1. Core 3.0 can extend or provide alternative implementations that complement or perhaps in the future could lead to deprecation of OSLC Core 2.0 features.
    4.2. We could refine the list of MAY and SHOULD conformance criteria details by doing a survey of what current clients and servers actually used if compatibility with 2.0 would lead to undesirable technical debt in Core 3.0



> 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)