I'm a new GeoNetwork user and having a hard time to understand how to solve metadata validation errors.

I need to start with a very basic question. GeoNetwork validation runs a Schema Validation (XSD validation) and a Schematron validation for ISO 19115(19139). Both return errors, but the XSD Validation in much higher numbers.

Having some XSD validation errors but no errors for Schematron validation for ISO 19115(19139) means the metadata conforms to ISO standard.

What is exactly happening?


Putting aside the GeoNetwork part of things, XML schema validation and XML schematron validation are testing two different aspects of the validity of the metadata.

XML schema validation tests the validity of the XML metadata record (XML instance) to rules on the structure of the XML according to the XML schema (one or more) referenced by the XML document.

You should probably fix these issues first.

XML schematron tests additional conditions in the XML instance.

For example in the below XML instance, a schema validator might tell us that there is an abstract element missing:

        <!-- there should be an abstract here -->
                    <gco:CharacterString>Ordnance Survey, 


Invalid content was found starting with element '{"http://www.isotc211.org/2005/gmd":pointOfContact}'. One of '{"http://www.isotc211.org/2005/gmd":abstract}' is expected.

but the following schematron rule (issue) would not be notified (because it requires an abstract element to be present before it can check its length).

<sch:pattern fpi="metadata/2.0/req/common/resource-abstract-len">
    <sch:title>Abstract length check</sch:title>
    <sch:rule context="//gmd:abstract/*[1]">
      <sch:assert test="string-length() &gt; 99"> MI-4b (Abstract): Abstract is too short. GEMINI 2.3 requires
        an abstract of at least 100 characters, but abstract "<sch:value-of
          select="normalize-space(.)"/>" has only <sch:value-of select="string-length(.)"/>
        characters </sch:assert>
  • Thanks nmtoken, that helped to clarify my understanding of the issue. Still a lot of "breaking stones in the hot sun" to fix all validation errors I'm getting, and since I'm importing xml coming from an older GeoNetwork version, shouldn't that be running smoothly? I’ve already fixed some schematron validation errors editing inside GeoNetwork using the edit form, and XSD validation error - Attribute 'id' must appear on element 'gml:TimePeriod'. (Element: gml:TimePeriod with parent element: gmd:extent) - using a XML editor. But still a lot of errors and a load of data… Jun 4 '19 at 8:27
  • Certainly if you're validating against the same XSD and schematron, you wouldn't expect that would be a difference, unless the validation rules were known to be broken and fixed in the new version.
    – nmtoken
    Jun 4 '19 at 9:44
  • Also there is no requirement for any geonetwork instance to validate the metadata it holds, so just harvesting from a geonetwork instance, won't guarantee that it is valid
    – nmtoken
    Jun 4 '19 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.