Undeclared prefix- cannot resolve xs:integer

[archaeogeek]

Validating the sample World Mineral Statistics Dataset provided with Gemini 2.3 in Geonetwork 3.8 I get the following error: UndeclaredPrefix: Cannot resolve 'xs:integer' as a QName: the prefix 'xs' is not declared. (Element: gco:Record with parent element: gmd:value)

This seems to be related to the Topological consistency element

The only guidance I have on this is from the main INSPIRE Technical Guidance, and it seems correctly encoded compared to those guidelines.

I tried adding the xs prefix to the record, but when I save it, it is removed. If that is the solution, then

1) what process is removing it- is it update-fixed-info? 2) how can I ensure it's automatically added to all records so this doesn't re-occur?

Thanks

Jo

[josegar74]

I haven't try in GeoNetwork, but in Oxygen using the schemaLocation in the metadata (http://inspire.ec.europa.eu/draft-schemas/inspire-md-schemas/apiso-inspire/apiso-inspire.xsd) and get the same errors:

Is really required the xsi:type="xs:integer" by GEMINI 2.3 spec?

[archaeogeek]

@josegar74 I think it should be real or double- see the encoding guidelines at https://www.agi.org.uk/agi-groups/standards-committee/uk-gemini/40-gemini/1062-gemini-datasets-and-data-series#52

The value type of the result shall be declared using the xsi:type attribute of the gco:Record element. Note that many of the INSPIRE Data Specifications give a value type of “Real, percentage, ratio”; GEMINI recommends using real numbers in all these cases, which should be declared as xs:double

However if I change it to xs:double I still get an error that the prefix is not declared, as I'd expect.

[josegar74]

@archaeogeek I notice something strange in the sample MEF, it has 2 files metadata.xml and metadata-iso19139.xml

• metadata.xml validates fine in OxygenXML

<gmd:value>
  <gco:Record xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xsi:type="xs:integer">12</gco:Record>
</gmd:value>

• metadata-iso19139.xml doesn't validate and probably the one loaded in the samples import in GeoNetwork:

<gmd:value>
  <gco:Record xmlns:gco="http://www.isotc211.org/2005/gco" 
    xsi:type="xs:integer">12</gco:Record>
</gmd:value>

It doesn't have the namespace xmlns:xs="http://www.w3.org/2001/XMLSchema" inline or in the root element, and that seem the cause.

Probably need to be checked the MEF export if this sample was created with that option.

But for now as the MEF is just a ZIP file I would fix the content of the xml to include that namespace in the root element and also check the templates to verify that include it also.

[archaeogeek]

@josegar74 I created the original mef files- the original files are here: https://github.com/AGIGemini/Schematron/tree/master/samples and in the appendices here https://www.agi.org.uk/40-gemini/1048-uk-gemini-encoding-guidance. This specific one is https://github.com/AGIGemini/Schematron/blob/master/samples/BGSds-example1c.xml.

To create the mef files I changed the schema name and version to Gemini 2.3, loaded them in to Geonetwork and then exported them back out as zip files and renamed them so I could load them using the admin interface as sample records. Was that the correct process?

I think I might need to include some method of inserting that root element if it's not included. Would that go in update-fixed-info?

[archaeogeek]

@josegar74 so further investigation suggests that the mef export creates a metadata-iso19139.xml file that contains no namespaces in the root. Is this deliberate? Is it something I need to fix?

[archaeogeek]

@josegar74 so manually fixing the metadata-iso19139.xml record in the mef does seem to work, so the issue that now needs resolving is why the zip export is stripping the namespace declarations from the records?

[josegar74]

I imported https://raw.githubusercontent.com/AGIGemini/Schematron/master/samples/BGSds-example1c.xml in 3.8 server, without GEMINI 2.3, so the metadata is assigned to ISO19139 schema, exporting to MEF has only metadata.xml and it's ok.

So most probably the issue is with https://github.com/AstunTechnology/iso19139.gemini23/blob/3.8.x/src/main/plugin/iso19139.gemini23/convert/to19139.xsl

I suspect is due to this: exclude-result-prefixes="#all" as the xmlns:xs namepace is declared in the element, but not really used, except in the value of xsi:type so probably is removed.

I would change to exclude-result-prefixes="geonet", let´s check if then xmlns:xs is kept and if there's any unwanted namespace we can extend the list.

[archaeogeek]

@josegar74 I think I've resolved this in https://github.com/AstunTechnology/iso19139.gemini23/commit/2e40151fd9c339f6a92e6e6d689792125719200e. I have kept it as a separate branch for now, so you can check it. Just changing to exclude-result-prefixes="geonet" did not work as the export still did not contain the xmlns:xs namespace declaration, so I have copied what we had for Gemini 2.2 which explicitly added the namespace declarations in. I had to change xmlns:gml and add xmlns:xs but exporting and re-importing now seems to produce a valid record. Could you look at what I've done to make sure it's OK? Thanks!

[josegar74]

@archaeogeek I have done some updates to the conversion, to preserve the schemaLocation

[archaeogeek]

Seems to be fine, so I will merge into 3.8.x and close this