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

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

Service provider catalog:
I think this is one of the areas that can require extra effort on the part of server implementors (is that what you meant by "technical debt"?), but I doubt we can do much about that, as it is a critical piece of backwards-compatibility. All I can think of doing is making sure that Eclipse Lyo (and preferably a protocol converter-style server too) can produce an entire catalog from the other kind of discovery (so a server can implement the newer approach, and as part of its compliance with OSLC include the library or converter to provide the catalog form). So then the burden on the server implementors may be a question of include the appropriate library or converter process - they don't have to implement it themselves if they don't want to. The consequence of that is that we have to make sure that all information that is required in the service provider catalog is also required in the newer discovery mechanism.

Query capability:
It makes sense to reference this. In terms of core I don't believe this is a MUST. It being a MUST would introduce a lot of extra effort by the server implementors. I know at least one domain specification (Automation) makes query a MUST on at least one type of its resources (but at least one implementation doesn't implement it fully). I know that's a problem for that spec, not for core directly, but I'm mentioning here as it's on the topic of compatibility & implementation burden.

Resource shapes:
In my opinion, I expect that we can remove some properties from resource shapes without causing backwards-compatibility problems. If a property is zero-or-more or zero-or-one at v2, then I expect we can remove it without a problem - its absence from the shape doesn't prevent it from being used either by clients or servers. I expect we can neither add nor remove properties with other cardinalities. Also, I expect adding properties should be limited in the same way - we can only give new properties cardinalities of zero-or-one or zero-or-more.

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