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

Martin Pain  commented on OSLCCORE-5:
-------------------------------------

For a v3 server and a v2 client, using capabilities that are in both versions: either the server chooses to implement both versions, or use an intermediate proxy/gateway server to convert between the versions. I expect server implementors won't want to implement both, so I'd suggest it's important for us to implement the conversion server & distribute it through Eclipse Lyo so it's easily available.

For a v2 server and a v3 client, using capabilities that are in both versions: either the client chooses to implement both versions, or use an intermediate proxy/gateway server to convert between the versions. As above, I would not expect clients to want to implement both.

So far I have only thought about discovery. If we want to benefit from LDP at all, I think we need to break backwards compatibility. I think creating conversion code that can either be downloaded & run, or incorporated into implementors' own products, is VERY important to enable uptake of v3 (and to preserve the implementation effort in v2).

As for individual domains, I would suggest making them backwards-compatible. But I do not know most of the domains well enough to know how much of a burden that would be on implementors of v3.

As for capabilities that are not being included in the current v3 work: the domain that I have worked with (Automation) is one of these, and in this particular case the v2 spec is silent (or implicit rather than explicit) about some of the parts that rely on core v2 discovery (that is, that rely on service providers & services). For using this capability from a v3 server, I think you will at least need an oslc:Service (defined in v2 and not in v3), but discovery of that (on a v3 server) can be via an LDPC (as long as the conversion code/server can correctly map that onto v2 catalogs & service providers).
However, I would expect implementors of these domains are more likely to either just implement v2 or implement both versions (using whatever compatibility/interoperability notes we produce), as their target consumers are more likely to be v2-only.

So, I suggest we break backwards compatibility for discovery, but provide conversion code (including as a download that can run as a standalone server) to convert both ways between v2 and v3 (where possible). But try to keep backwards-compatibility in individual domains. And produce notes on how to be natively compatible with v2 and v3 (hopefully without detecting the client's desired version). And produce notes on how to link to domains/capabilities that are only defined in v2.

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