md-iso.c.6 Dataset geographic bounding box fails unexpectedly

[PeterParslow]

My record has a bounding box of "west-bound longitude = '-8.655', east-bound longitude = '1.79', south-bound latitude = '49.9', north-bound latitude = '60.85'."

The validator fails it
"The metadata record set has 1 record(s) with errors for this assertion.
XML document 'OSOpenNames.xml', record 'd442b64c-c8c8-11e4-8731-1681e6b88ec1': A dataset (series) metadata record must have a valid bounding box that defines the extent of the resource in geographic space. The bounding box is valid if: 1) it has four coordinates (given in decimal degree with a precision of at least 2 decimals), 2) both west- and east-bound longitude are greater than or equal to -180.00, and smaller than or equal to 180.00, 3) both south- and north-bound latitude are greater than or equal to -90.00, and smaller than or equal to 90.00, 4) south-bound latitude is smaller than or equal to north-bound latitude. At least one of these criteria is not fulfilled for one of the geographic bounding boxes of this metadata record. The provided values of this bounding box are: west-bound longitude = '-8.655', east-bound longitude = '1.79', south-bound latitude = '49.9', north-bound latitude = '60.85'."

Don't forget to include:

• [ http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp/v2/TestRuns/EIDa7ee9f56-5ff6-4c0d-94f6-c7bbdeb77198.html] a link to the Test Report
• [http://inspire-sandbox.jrc.ec.europa.eu/etf-webapp//v2/TestRuns/EIDa7ee9f56-5ff6-4c0d-94f6-c7bbdeb77198.html?lang=en#EID38e03270-2c5c-4e15-af35-8eb9c25ecc43 ] the name of the Test that failed or better: change the Level of Detail
  in the Report by clicking on All Details, then scroll down to the failed test
  and copy the Link on the right-hand side of the Assertion URI
• [https://www.ordnancesurvey.co.uk/xml/products/OSOpenNames.xml ] the URL of your service / the file you have uploaded or referenced.

[fabiovin]

Dear Peter,
I had a look at your metadata file and I detected that the content of the attribute "xsi:schemalocation" are not correct, indeed the schema validation fails. I substituted the content with the following value: "http://www.isotc211.org/2005/gmd http://schemas.opengis.net/iso/19139/20070417/gmd/gmd.xsd http://www.isotc211.org/2005/gmx http://schemas.opengis.net/iso/19139/20070417/gmx/gmx.xsd", and the schema validation is ok.

Regarding the bounding box error, the test fails because it checks that at least two decimals are present. So, if you use the value "49.90" instead of "49.0" the test passes.

Ciao,
Fabio

[PeterParslow]

Given that gmx.xsd (indirectly) imports gmd.xsd, I did not expect to have to mention both in the schemaLocation. (This is true in both the opengis.net and standards.iso.org cases). It validates as is in Oxygen (and I have checked, that does include validating the gmd namespace). That's long been a problem with XML validation: different results from different validating parsers.

I had wondered about the schema validation failing - I knew it used to have problems with https redirects - so I ignored it & moved on to the INSPIRE specific tests.

Thanks for pointing out my boundingBox error - I'll fix that.

[fabiovin]

You're right, XMLSpy also validates the metadata with only the gmx schema declared in the "schemalocation" attribute. But, as you wrote: "different results from different validating parsers".

The https redirect issue doesn't affect the schemas available in the opengis.net repository, so they can be successfully used.

[PeterParslow]

I've just checked, by changing the schemaLocation to "http://www.isotc211.org/2005/gmx http://schemas.opengis.net/iso/19139/20070417/gmx/gmx.xsd" - it still fails:

XML document 'OSOpenNames.xml': The file has 3 schema validation error(s).
XML document 'OSOpenNames.xml': 1:435: cvc-elt.1.a: Cannot find the declaration of element 'gmd:MD_Metadata'.

So then I tried with both XSDs mentioned, from 'my preferred place': "http://www.isotc211.org/2005/gmx https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmx/gmx.xsd http://www.isotc211.org/2005/gmd https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd" - that passes

So it isn't the ISO vs OGC records, or an HTTPS issue; it does seem to be a problem parsing the imports.

I'm confident that my file is schema valid, and follows one of the options in TG Requirement C.1

It validates at http://inspire-geoportal.ec.europa.eu/validator2/

[fabiovin]

It seems that it is not able to parse the gmd schema from the gmx one.

Trying with the ISO https schemas (http://www.isotc211.org/2005/gmx https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmx/gmx.xsd http://www.isotc211.org/2005/gmd https://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd) I obtain a different result, the metadata validation fails with both XMLSpy and INSPIRE Validator.

In the end, it seems that there is the issue with the https redirects and also an issue with the parsing of the imported schemas (even though it appears only with the gmx schema).

[fabiovin]

FYI
Related open issue: https://github.com/etf-validator/etf-webapp/issues/197

[PeterParslow]

That's very strange: "Trying with the ISO https schemas" succeeded for me in both Oxygen & the INSPIRE Validator a couple of days ago, but then fails for you in the INSPIRE Validator!

Today, it still validates in Oxygen, but INSPIRE validation fails for me too: "premature end of file"

[nmtoken]

Schema location though is only a hint, the validator should use it's own version of the appropriate schema to do validation. It shouldn't be a validation error for an XML instance to reference a schema that is not accessible to the INSPIRE validator.

[fabiovin]

The validator uses:

• schemas declared in xsi:schemaLocation for the version 1.3
• fixed schemas for the version 2.0

To overcome http to https redirect issue, we created a modified version of the apiso-inspire.xsd schema that now refers to ISO/TC 211 XML Schemas available on the OGC schema repository instead of the ISO repository (where resources have been moved to HTTPS). This version is now used by the Metadata 2.0 test suite.