Open ghost opened 5 years ago
The issues I have discussed in https://inspire.ec.europa.eu/forum/discussion/view/261514/geonetwork-gmxgmdci-datetype-validation-issues and inspire-eu-validation/community#107 and inspire-eu-validation/community#106
Are similar to the ones DeorD discusses as they also seem to be caused by changes made by Geonetwork to the saved metadata file. However the actual validation errors seem to be different.
Is this a Geonetwork issue or more an issue with the configuration of our Geonetwork installations. (Suggestions on how to fix our configuration are always welcome.)
I have tested with the metadata record before import and doesn't validate either with TG 2.0 or TG 1.3.
Results for TG 2.0:
I get the same results with the file https://github.com/geonetwork/core-geonetwork/files/3583604/metada_record_after_export.zip.
Please check if maybe the file https://github.com/geonetwork/core-geonetwork/files/3583601/metada_record_before_import.zip doesn't contain the correct metadata.
I see the follwoing changed before and after
before
<gmd:language>
<gmd:LanguageCode codeList="http://www.loc.gov/standards/iso639-2/" codeListValue="ger"/>
</gmd:language>
after
<gmd:language>
<gco:CharacterString>ger</gco:CharacterString>
</gmd:language>
before
<gmd:dateType>
<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication">publication</gmd:CI_DateTypeCode>
</gmd:dateType>
after
<gmd:dateType>
<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="publication"/>
</gmd:dateType>
Not sure why the first change occurs, this seems a bug, the second is not optimal, it's a current limitation of GeoNetwork, but I don't see why a validator would fail on that.
Thanks a lot for the analysis.
INSPIRE-Validator was updated since the last time metadata record was validated.
I will perform the same test with the same metadata record which is fully valid before import in Geonetwork 3.10.1.0 and give you my feedback on this topic before further analysis is done.
Dear @pvgenuchten , @josegar74
I have just fixed the metadata metada_record_before_import.zip.
I have succesfully validated metadata record against TG 2.0 on INSPIRE -Validatior staging instance before import.
Metadata was exported from Default view using Export (ZIP) functionality.
Metadata record is also valid on staging instance against the same conformance classes.
In my opinion this problem doesn't occur in 3.10.1.0. Only difference between two metadata records is in XML-Header and fileIdentifier value.
I didn't validate the metadata records against TG 1.3 because support period from INSPIRE ended in Dezemebr last year.
Can you confirm my findings? If yes, this issue can be closed in my opinion.
It's still happen in 3.12 and 4.2 versions !
Bug description Imported metadata record which is valid againt INSPIRE Validator Conformance Class 'INSPIRE Profile based on EN ISO 19115 and EN ISO 19119' record ist after export not valid against the same conformance class.
To Reproduce Steps to reproduce the behavior:
Similar behaviour is also discussed in INSPIRE Forum: https://inspire.ec.europa.eu/forum/discussion/view/261514/geonetwork-gmxgmdci-datetype-validation-issues and https://github.com/inspire-eu-validation/community/issues/107 and https://github.com/inspire-eu-validation/community/issues/106
Expected behavior Metadata should be valid after export.
Desktop (please complete the following information):