Closed jdvorak001 closed 1 year ago
Dear @jdvorak001 , thank you for raising this. I notice that the Compatibility classification inside the 'Service' entity at v1.1.1, there is only 2 classifications
I would support the (B) option as this already supports backward compatibility within version 1.1 (v1.1.0 and v1.1.1).
Correct! The 1.1.1 compatibility was actually added after the 1.1.1 release. If we keep the backwards compatibility of the micro versions, this compatibility level is not needed.
O.k., I'll go for option (B).
I'll also add additional rules in the validator that will require a metadata format in the ListMetadataFormats response if the corresponding compatibility level was declared in the Identify response (for the 1.1 and 1.2 compatibility levels).
Fixed in 1.2.0
While preparing the 1.2 release I got puzzled by the Compatibility classifications inside the
Service
CERIF element in the response to the OAI-PMH 2.0 Identify request.We currently have the following levels defined:
I'm finding this inconsistent. We should either:
(A) Define the admissible compatibility levels codes at the finest versions, defined by the released versions of the Guidelines so far (i.e. 1.0, 1.1.0, 1.1.1, 1.2.0).
(B) Be happy with having compatibility levels at the minor versions (i.e. 1.0, 1.1, 1.2), so get rid of 1.1.1.
In any case the Validator should check consistency between these compatibility statements and the OAI-PMH 2.0 metadata formats declared by the endpoint in response to ListMetadataFormats requests.
I personally do not see much value in having the micro version level compatibility statements, as we committed ourselves to backwards compatibility within the minor versions.