Dear helpdesk,
We are facing an issue related to new application schemas 2024.1 and 2024.2 (thus XSD v5.0), I'm not sure where to post this.
We are working with FME in order to write an INSPIRE-conform GML based on the new XSD:
The dataset here is a PhysicalWaters - Watercourse one. Therefore, I indicate these URLs into the XSD and the xsi:schemaLocations
`http://inspire.ec.europa.eu/schemas/hy-p/5.0 http://inspire.ec.europa.eu/schemas/hy-p/5.0/HydroPhysicalWaters.xsd http://www.opengis.net/gml/3.2 http://schemas.opengis.net/gml/3.2.1/gml.xsd http://inspire.ec.europa.eu/schemas/base/4.0 http://inspire.ec.europa.eu/schemas/base/4.0/BaseTypes.xsd http://inspire.ec.europa.eu/schemas/gn/4.0 http://inspire.ec.europa.eu/schemas/gn/4.0/GeographicalNames.xsd http://www.isotc211.org/2005/gmd http://schemas.opengis.net/iso/19139/20070417/gmd/gmd.xsd`
However, the output is not written properly and application schema 4.0 still appears (tag `hy-p4`). We suspect an issue with the XSD but couldn't find anything.
[HY.watercourse_v5.zip](https://github.com/user-attachments/files/17028922/HY.watercourse_v5.zip)
The issue might be related directly to FME but we'd rather first check if you can reproduce this issue and provide a solution.
Kind regards
Dear @antjacques,
it seems there is still an import of the hy-p schema version 4 by some other linked schema, but when opening the schema with Hale Studio the default feature types are those related to version 5 (see screenshot below).
So, these are used in the exported gml file.
It could be a FME issue or something that should be specified in the transformation project.
I would suggest opening an issue in the dedicated FME repository/helpdesk.
In the meantime, we will check if it is possible to avoid the import of the old version of the hy-p schema.
Thanks for your feedback @fabiovinci
The reason why we were reluctant to open a ticket at FME is because we successfully implemented new application schemas for other themes such as AU, TN, PS, NZ or HH. I forgot to mention it earlier, sorry.
The only bugs we have so far are linked to HY and US (ticket 1089 in the validator), so we were suspecting a problem in INSPIRE documents.
If you don't find anything else, we'll sure ask FME support.
Best regards
I am also confused that the [current HY-N schema](https://inspire.ec.europa.eu/schemas/hy-n/4.0/HydroNetwork.xsd) which is still version 4.0 is importing HY-Base in version 4.0 even though [HY-Base 5.0](https://inspire.ec.europa.eu/schemas/hy/5.0/HydroBase.xsd) is existing.
Shouldn't the latest schemas always import the latest versions of other schemas?
Same for [TN-A](https://inspire.ec.europa.eu/schemas/tn-a/4.0/AirTransportNetwork.xsd) and [TN-C](https://inspire.ec.europa.eu/schemas/tn-c/4.0/CableTransportNetwork.xsd) where the latest version existing (4.0) is not importing the latest version existing for TN (should be 5.0, is only 4.0).
@fabiovinci Do you have any input on if we can expect the current 4.0 HY-N and TN-A and TN-C schema to be updated so that they import the latest 5.0 version of their respective "base" schemas HY-Base and TN?
Or will they remain as they are and use the old 4.0 base schemas?
@fabiovinci It would be important to clarify the handling of the schema imports between the various versions so that data providers know with which namespaces to work. It would be great if you could provide some input on that soon.
Thank you and all the best, Johanna
Dear all,
I'm sorry for not getting back to you sooner.
We decided to fix these import errors and release them as a hotfix schema release.
It will be done in the next few weeks.
FYI regarding the writer issue in FME: I opened a ticket and apparently Safe Software forgot to edit a configuration file to implement entirely the new application schemas
https://community.safe.com/transformers-9/inspire-gml-writer-importing-wrong-xsd-35229
Hello @fabiovinci
I got an answer from FME support that enables me to fix this in FME. There seems to be an issue with the import of XSD anyway, here is what they noticed:
> Both v4.0 and v5.0 HydroPhysicalWater schemas are being pulled in, so that both v4.0 and v5.0 set of feature types are present and colliding when we don't add the namespace prefix to the FME feature type.
>
> In the INSPIRE Writer, and also perhaps the INSPIRE Reader, set the "Add XML Namespace Prefix to:" the "Feature Types" value, so that the namespace prefix can be added to the feature type, e.g., both v4.0 and v5.0 versions will now be present since the local-name collision will be resolved: "hy-p4_Watercourse" and "hy-p_Watercourse".
>
> Route the features to the hy-p_Watercourse to write to the v5.0 version.
>
> The following is how the v4 HydroPhysicalWaters element and types are being pulled in:
>
> hy-p\5.0\HydroPhysicalWaters.xsd imports hy-n\4.0\HydroNetwork.xsd
> hy-n\4.0\HydroNetwork.xsd imports hy\4.0\HydroBase.xsd
> hy\4.0\HydroBase.xsd imports hy-p\4.0\HydroPhysicalWaters.xsd
>
> This is how INSPIRE defined their schemas, local-names collide as both v4 and v5 elements and types are being pulled in, so they must be differentiated in the workspace.
I don't know if this helps you about the import of older schema but so you know.
> We decided to fix these import errors and release them as a hotfix schema release.
> It will be done in the next few weeks.
@fabiovinci Any news/timeline for that?
PS: Wishing you happy holidays! Thank you and the team for your patient and helpful support throughout the year!
Dear @JohannaOtt,
since the problem was resolved in FME and there was no similar issue in Hale, and considering the upcoming official release at the end of January 2025, it was decided not to publish a hotfix. Therefore, the fix will be included in the next official release.
Dear @JohannaOtt,
just to clarify that the changes @fabiovinci is referring to in [this comment](https://github.com/INSPIRE-MIF/application-schemas/issues/130#issuecomment-2459566774) will only regard the HY schemas ( creation of v5 for the HydroNetwork.xsd and update of HydroBase.xsd v5).
No change will be implemented for the TN-A and TN-C schemas . Reason is the same already explained in[ this issue](https://github.com/INSPIRE-MIF/application-schemas/issues/124) i.e., we do not want to break existing implementations for those schemas that are not affected by the specific change in the related new version of the imported schema.