NPE when converting ISO-19139 record with URN-like `fileIdentifier` to DCAT

[streino]

Describe the bug

The following ISO-19139 record causes a "Connection refused" when converted to DCAT.

• Record: https://data.lillemetropole.fr/geonetwork/srv/api/records/urn:isogeo:metadata:uuid:0e52938b-5200-4127-8e32-a39b34501f57
• XML view (OK): https://data.lillemetropole.fr/geonetwork/srv/api/records/urn:isogeo:metadata:uuid:0e52938b-5200-4127-8e32-a39b34501f57/formatters/xml
• DCAT conversion (KO): https://data.lillemetropole.fr/geonetwork/srv/api/records/urn:isogeo:metadata:uuid:0e52938b-5200-4127-8e32-a39b34501f57/formatters/dcat

Log file

From 4.4.9 docker image:

2026-05-05 18:04:40.675:INFO:oejs.Server:main: Started @21723ms
Error at xsl:apply-templates on line 171 of dcat-core.xsl:
  Exception in extension function java.lang.RuntimeException: java.lang.NullPointerException
2026-05-05T18:05:44,394 ERROR [geonetwork] - Exception in extension function java.lang.RuntimeException: java.lang.NullPointerException
net.sf.saxon.trans.XPathException: Exception in extension function java.lang.RuntimeException: java.lang.NullPointerException
	at net.sf.saxon.functions.ExtensionFunctionCall.call(ExtensionFunctionCall.java:368) ~[saxon-9.1.0.8b-patch.jar:?]
        ...
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
	at org.fao.geonet.api.records.MetadataUtils.getAssociatedAsXml(MetadataUtils.java:183) ~[gn-services-4.4.9-0.jar:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
	at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
	at net.sf.saxon.functions.ExtensionFunctionCall.invokeMethod(ExtensionFunctionCall.java:690) ~[saxon-9.1.0.8b-patch.jar:?]
	at net.sf.saxon.functions.ExtensionFunctionCall.call(ExtensionFunctionCall.java:343) ~[saxon-9.1.0.8b-patch.jar:?]
	... 161 more
Caused by: java.lang.NullPointerException
	at org.fao.geonet.api.records.MetadataUtils.getAssociated(MetadataUtils.java:205) ~[gn-services-4.4.9-0.jar:?]
	at org.fao.geonet.api.records.MetadataUtils.getAssociatedAsXml(MetadataUtils.java:158) ~[gn-services-4.4.9-0.jar:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
	at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
	at net.sf.saxon.functions.ExtensionFunctionCall.invokeMethod(ExtensionFunctionCall.java:690) ~[saxon-9.1.0.8b-patch.jar:?]
	at net.sf.saxon.functions.ExtensionFunctionCall.call(ExtensionFunctionCall.java:343) ~[saxon-9.1.0.8b-patch.jar:?]
	... 161 more

Additional comments

I suspect the URN-like fileIdentifier "urn:isogeo:metadata:uuid:0e52938b-5200-4127-8e32-a39b34501f57" to cause this issue. Possibly related to #9170.

[streino]

I confirm this is caused by the URN-like fileIdentifier.

core-geonetwork/services/src/main/java/org/fao/geonet/api/records/MetadataUtils.java

Line 152 in 7e13e32

AbstractMetadata metadataEntity = metadataUtils.findOneByUuid(metadataUuid);

In the debugger, on the above line, metadataUuid = "isogeo:metadata:uuid:0e52938b-5200-4127-8e32-a39b34501f57", but should be "urn:isogeo:metadata:uuid:0e52938b-5200-4127-8e32-a39b34501f57".

I believe this is caused by the following XSL call, only taking code without codeSpace :

core-geonetwork/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/formatter/dcat/dcat-core-resource.xsl

Line 76 in 7e13e32

select="mdUtil:getAssociatedAsXml(mdb:metadataIdentifier/*/mcc:code/*/text())"

IMO it would be less risky to keep an ISO-19139 fileIdentifier as-is in code, instead of trying to extract a codeSpace, which isn't spec'ed in ISO-19139, and risk running into issues putting it back together (this won't fix #9232, but will fix this bug and #9170).

@fxprunayre what was the reasoning for splitting ISO-19139 fileIdentifier when converting records ISO-19115.3?

[fxprunayre]

@fxprunayre what was the reasoning for splitting ISO-19139 fileIdentifier when converting records ISO-19115.3?

It comes from https://github.com/ISO-TC211/XML/blob/master/standards.iso.org.annotated/iso/19115/resources/transforms/ISO19139/mapping/core.xsl#L23-L28
and in the context of GeoNetwork using random UUID it was not causing issue but in your case you can adapt the conversion if needed.

[streino]

Thanks for the pointer, I wasn't aware of this reference implementation.

By "adapt the conversion", I assume you mean the catalog having their own modified version of the XSL?
Even then, I believe the NPE is still a concern for GN, since it would affect any other catalog harvesting that record in ISO and re-exposing it in DCAT.

[fxprunayre]

Maybe it is better to preserve gmd:fileIdentifier in the 19139 > 19115-3 conversion to mdb:metadataIdentifier?

[streino]

Ideally the full namespace (urn:isogeo in my example above) would be extracted and properly handled. But I've encountered several namespace-related bugs recently, so a pragmatic fix could be to preserve the identifier as-is until those other bugs are ironed out?