OpenAIRE_Service_Compatibility for version 1.1.1

[spyroukostas]

The OpenAIRE Guidelines for CRIS have the following versions:

• 1.0
• 1.1
• 1.1.1
• 1.2

Most of the registered CRIS are compatible with the 1.1.1 version. But this version has been removed from the Service Compatibility enum under schemas/vocabularies/openaire_service_compatibilities.xsd since the commit c336f34.

Is this correct?
Thank you in advance.

[jdvorak001]

While working towards 1.2.0 we had a bit of a dilemma with this vocabulary: the vocabulary didn't contain an entry for compatibility with the 1.1.0 version. The question was: so should it?

Any micro-level updates are extensions only (if they need to touch any of the XML schemas, that is). We took the more coarse-grained way and only declared compatibilities down to the minor version. This currently means 1.0, 1.1 and 1.2. This is also the level of granularity that a harvester can use for selecting the OAI-PMH metadata schema (based on the XML namespace). Thus, if 1.2.1 is released, it will only extend 1.2.0 and will use the same XML namespace (https://www.openaire.eu/cerif-profile/1.2/) as 1.2.0 does.

I believe that on the consumer side, the best approach is to consider the 1.1.1 compatibility level as equivalent to the 1.1 one. Just make sure you use the latest XML schemas of any of the minor release branches.

[spyroukostas]

Thank you for clarifying. The issue is that this compatibility was introduced five years ago and remained in the documentation for four years. Many registered CRIS had already adopted it before it was removed.

I believe version 1.1.1 shouldn't be removed. Instead, it should be marked as deprecated, with version 1.1 encouraged for use in its place.

What are your thoughts?

[jdvorak001]

Yes, had we wanted to keep backwards compatibility, we should have deprecated the 1.1.1 compatibility level entry instead of removing it. But that would have to happen in a tentative 1.1.2 release.

Since 1.2 is not backwards compatible with 1.1, it was o.k. to remove it altogether.

[pispis]

Thank you Jan.

The issue here is that the customers have been using the 1.1.1 guidelines for several years and this should remain as is because we cannot mark it as deprecated and encourage them to use the 1.1 version. Let's not complicate things with another release here as you should take into mind that we are not talking only for the validator here but also for the guidelines. And the customers do not differentiate them as we do technically.

We are going to release version 1.2 in the next months but version 1.1.1 should remain accessible in the guidelines as most of the registered CRIS follow this version as it was mentioned until June 2023.

[spyroukostas]

I just came across this issue about the Service Compatibility.

I understand that the option for Service Compatibility version 1.1.1 was introduced after the publishing of the version 1.1.1 of the guidelines. At this point you were working for the version 1.2.0 of the guidelines and you decided to remove the Compatibility 1.1.1 option. Did I get it right?

However, while you were working on version 1.2.0, the Compatibility version 1.1.1 option existed in the documentation and it was later removed (e4b8803).

My question is, was this option publicly mentioned in the docs v1.2.0 and was later removed, or was it never mentioned publicly?

Thank you.

[jdvorak001]

You're right. We didn't have the 1.1.1 compatibility level in the 1.1.1 release itself. Nor was it present in the 1.2.0 release.

It was present in the development branch for some time (commits e64a251 to c336f34 for the schema, e64a251 to e4b8803 for the documentation) between these two releases. It was displayed on the ReadTheDocs site.

[jdvorak001]

It looks like the easiest way out of this trap would be to make a technical 1.1.2 release that would include the 1.1.1 compatibility level as deprecated one. That would give us a XML schema in the 1.1 namespace that would include this compatibility level. What do you think, @spyroukostas?

[spyroukostas]

I understand this is a difficult situation, as the releases have already been published. One option, as you mentioned, is to create another technical release (1.1.2) and possibly a 1.2.1 release to include the deprecated Compatibility version in the guidelines 1.2 docs.

But the problem I see in this option is that the versions of the guidelines may be confused with the release versions of the repository by the users. So isn't it going to appear that new guidelines have been introduced and further confuse the users?

Nevertheless, I don't think I should decide on this matter, and we certainly shouldn't rush into anything that could complicate matters further.

Probably you have to hear to what @pispis believes to be better.