Skip to main content
  • EN

Hi,

 

I made a workspace to create INSPIRE datasets. When checking whether the created INSPIRE GML is valid, I wanted to add an XML Schema Validation step into the process. When doing so however, I noticed that in FME's XMLValidator I get two Validation Errors;

  1. no declaration found for element 'so:soilProfileObservation'
  2. element 'so:soilProfileObservation' is not allowed for content model '(metaDataProperty*,description?,descriptionReference?,identifier?,name*,boundedBy?,location?,inspireId?,localIdentifier?,WRBSoilName,otherSoilName*,validFrom,validTo?,beginLifespanVersion,endLifespanVersion?,isDescribedBy+,location)'

 

See also below screenshot;

3_FME_XSDValidator_Unique_Validation_ErrorsIf I however validate the GML using either (the XMLTools plugin) of Notepad++, or INSPIRE's validator, the GML does validate.

 

Does anyone know what causes these validation errors of FME's XMLValidator?

If I check the second (unique) error that, i.e. that the element soilProfileObservation is not allowed in the content model, it seems that that element is indeed not listed in the derived/fetched content models elements. However, to me it seems that that element is part of the XSD that was used for validation (https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), albeit it could be part of sub XSD's that are included in that main XSD.

 

So to me it seems that this might be a bug in FME's XMLValidator. Especially since two other validation suites/methods don't result in validation errors. But I'm curious to hear other people's ideas on this.

 

Kind regards,

 

Thijs

 

ps. See attached files for the workspace, dataset, INSPIRE validation report and some screenshots.

Hello @thijsknapen​, thanks for posting to the Community! I think this is being caused by the local schema shipped with FME Workbench. It looks like we need to update our local inspire schema, soil.xsd in this case.

 

A workaround for the time being, would be to download the updated schema from https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd (Right-click > Save As...) and then replace it in <FME Installed Dir>/xml/schemas/inspire/so/4.0/Soil.xsd. Once you replace the XSD file and restart Workbench, your dataset should pass the XMLValidator.

 

Please let me know if you still have issues after replacing the XSD. I will set some time aside to file an issue with development. Happy to help, Kailin

 

*Note: make sure to save the original copy of soil.xsd incase something goes wrong!!

Hello @thijsknapen​, thanks for posting to the Community! I think this is being caused by the local schema shipped with FME Workbench. It looks like we need to update our local inspire schema, soil.xsd in this case.

 

A workaround for the time being, would be to download the updated schema from https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd (Right-click > Save As...) and then replace it in <FME Installed Dir>/xml/schemas/inspire/so/4.0/Soil.xsd. Once you replace the XSD file and restart Workbench, your dataset should pass the XMLValidator.

 

Please let me know if you still have issues after replacing the XSD. I will set some time aside to file an issue with development. Happy to help, Kailin

 

*Note: make sure to save the original copy of soil.xsd incase something goes wrong!!

Hi @kailinatsafe,

 

Thanks for the response. I tried the workaround you suggested, and indeed that works for me :)

 

I am a bit confused though why I need to apply this workaround. If I'm routing the XMLValidator to an external schema/resource (i.e. provide it with the URL https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), why does it still seem to use locally stored XSD files? Is that maybe due to performance reasons? (i.e. to avoid having to download commonly used resources/schema's in FME?)

 

Kind regards,

 

Thijs

 

Hi @kailinatsafe,

 

Thanks for the response. I tried the workaround you suggested, and indeed that works for me :)

 

I am a bit confused though why I need to apply this workaround. If I'm routing the XMLValidator to an external schema/resource (i.e. provide it with the URL https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), why does it still seem to use locally stored XSD files? Is that maybe due to performance reasons? (i.e. to avoid having to download commonly used resources/schema's in FME?)

 

Kind regards,

 

Thijs

 

Hello @thijsknapen​, thanks for highlighting that, I completely missed your schema URL when I initially looked - apologies! I believe this is design choice of FME Desktop. I believe for inspire-based stuff we default to local mapping. In the underlying xfmap code for majority of XML transformers/readers/writers, when a schema is supplied or detected, we check for a local copy of the same schema. In the logfile, you should see a log redirecting the URI to the local schema file:

URI 'https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd' mapped to 'file:///C:/FME-build-beta/xml/schemas/inspire/so/4.0/Soil.xsd'

Do you see this message? I think this choice was made to always try and grab the most up-to-date schema (which for inspire, should be included with fme install). In this case, we were the ones causing issues by having an outdated soil.xsd in the fme install folder. I’ll chat with development and see if there is anything we can do to improve this process. Thanks for bringing this to our attention! Happy to help, Kailin. 

Hi @kailinatsafe,

 

Thanks for the response. I tried the workaround you suggested, and indeed that works for me :)

 

I am a bit confused though why I need to apply this workaround. If I'm routing the XMLValidator to an external schema/resource (i.e. provide it with the URL https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), why does it still seem to use locally stored XSD files? Is that maybe due to performance reasons? (i.e. to avoid having to download commonly used resources/schema's in FME?)

 

Kind regards,

 

Thijs

 

Hi @kailinatsafe​ 

Thanks for the additional info. I believe I have seen messages on URI/XSD mappings in te log in the past, but I never really payed attention to it. Now I know these might be helpfull in debugging issues like this in the future, so tnx 🙂

 

I had a look in the log, but the above message doesn't show up. Furthermore, both before, and after having updated the local INSPIRE Soil XSD file, I see the following message in the log;

XMLValidator (XMLValidationFactory): Using external XSD document: 'https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd'

 

I think the mention that an external XSD document is used, might be a bit confusing for users.

If I dig a bit deeper, a few lines above the previous message, I also see the following message in the log (again both before and after having updated the local INSPIRE soil xsd);

The uri-map document 'C:\Program Files\FME_2022.1\xml\urimap\gml_inspire.xml' is being used to map from URI to URI.

 

In the mentioned file, I can deduce the indicated behaviour. Specifically, I found the following two elements for the uri-map;

<uri-map>
<!-- auto-generated INSPIRE uri-map with xsds from http://inspire.ec.europa.eu/schemas - 20151014 -->
...
<schemaLocation namespace="http://inspire.ec.europa.eu/schemas/so/4.0" location="https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd"/>
...
<namespaceURI in="http://inspire.ec.europa.eu/schemas/so/4.0" out="../schemas/inspire/so/4.0/"/>
...
</uri-map>

The XML comment has me a bit worried, i.e. I hope the INSPIRE XSD files of FME have been updated more recently than 20151014.

Kind regards,

Thijs

 ps. Attached you can find the log files I obtained.

 

 

 

 

Hi @kailinatsafe,

 

Thanks for the response. I tried the workaround you suggested, and indeed that works for me :)

 

I am a bit confused though why I need to apply this workaround. If I'm routing the XMLValidator to an external schema/resource (i.e. provide it with the URL https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), why does it still seem to use locally stored XSD files? Is that maybe due to performance reasons? (i.e. to avoid having to download commonly used resources/schema's in FME?)

 

Kind regards,

 

Thijs

 

Thanks for the logs @thijsknapen, I'll take a look and get back to you!​

Hi @kailinatsafe,

 

Thanks for the response. I tried the workaround you suggested, and indeed that works for me :)

 

I am a bit confused though why I need to apply this workaround. If I'm routing the XMLValidator to an external schema/resource (i.e. provide it with the URL https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), why does it still seem to use locally stored XSD files? Is that maybe due to performance reasons? (i.e. to avoid having to download commonly used resources/schema's in FME?)

 

Kind regards,

 

Thijs

 

Hello @thijsknapen​, thanks for your patience! We determined the URI mapping message got accidnetally hidden in log debug mode, we will pull this into the general logging so it is more obvious to users! Thanks again for catching this! Also, FMEENGINE-75788 was filed to update the local inspire soil.xsd.

 

Regarding the XML comment, this is nothing to be alarmed of, the number does not reflect the date of the schema, but an internal mapping table/dict reference. Please let me know if there are any other questions/comments! Happy to help, Kailin.

Hello @thijsknapen, I'm happy to inform you FMEENGINE-75788 has been resolved in FME 2023.0 Beta Build23215+! You can find the latest version of FME on our Downloads Page. Also, there is a new log message (which does not require debug mode) that will specify what copy of the .xsd that the parser is using. Thanks again Thijs! 😀

Hello @thijsknapen, I'm happy to inform you FMEENGINE-75788 has been resolved in FME 2023.0 Beta Build23215+! You can find the latest version of FME on our Downloads Page. Also, there is a new log message (which does not require debug mode) that will specify what copy of the .xsd that the parser is using. Thanks again Thijs! 😀

Thanks for the update @kailinatsafe​, sounds great! :)

Reply


Community Stats

30,126
Posts
114,372
Replies
37,764
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.