Could we adopt defensive coding against issues with the external resource files?

[PeterParslow]

For a few days after the AGI website migration, the two resource files were unavailable.

https://agi.org.uk/images/xslt/MD_CharacterSetCode.xml and https://www.agi.org.uk/images/xslt/d4.xml

This was probably what caused my GeoNetwork instance to start providing an unexpected error message, failing MI-51 even though the Character set encoding element looks fine:

<gmd:characterSet>
<gmd:MD_CharacterSetCode codeList="http://standards.iso.org/iso/19139/resources/gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8"/>
</gmd:characterSet>

They're back now. But I'm still getting an error; I suspect some server - server communication problem. That of course isn't something that the schematron files could fix, but they could help diagnose.

My suggestion is to include an assertion just after each file is loaded which would give a message if something had gone wrong there. For example, after line 111-112 which loads the MD_CharacterSetCode.xml file, how about

<sch:assert test="count($charSetCodes//gml:identifier) > 0">
MI-XX check loading of $charSetCodes; it appears to contain no gml:identifiers
</sch:assert

[archaeogeek]

The issue is with the AGI web certificate- only requests with www in the URL are being handled correctly. I think we should look at hosting the xml files either locally or within github

[PeterParslow]

@archaeogeek : thanks; it's a very subtle sort of "URL change" at AGI's end, then.

Your suggestion would be "defensive programming" for particular servers - I think it would be a sensible approach, so I'm happy to go that way for the OS system.

Perhaps this issue can remain open for further discussion as to whether the AGI GEMINI Schematron files could contain a statement that could help debug any similar issues in future.

[PeterParslow]

Or did you mean "locally within this GitHub repository", rather than a link out to the AGI site?

That would make sense, given that we've moved the Schematron file here.

Note that the MD_CharacterSetCode file is already a copy of the official ISO one, or rather an extract of it, in order to reduce the size of the file being processed. But also to defend against unexpected changes on the ISO & ISO TC211 resource sites!

[archaeogeek]

@PeterParslow I did mean storing them in this repository, yes. @nmtoken mentioned potentially having an issue with that approach but I think we should explore it further.

[nmtoken]

As long as the raw version is the exact copy of the original, then it should be OK.

[PeterParslow]

So we could copy them to here and see if an appropriately adjusted Schematron file works?

I think we would then leave them in both locations for quite some time, because all those local copies of the Schematron files embedded in GeoNetwork instances, data.gov.uk, and presumably the UK Location MDE would still be pointing at the AGI copies.

[archaeogeek]

I'm in the middle of checking whether a local copy (in this case, downloaded to the schematron folder in the geonetwork plugin) works. We really need AGI to fix the certificate problem though, because we can't know for sure whether any other implementations will hit the same issue (is it only geonetwork, is it dependent on operating system, deployment method etc etc).

[PeterParslow]

I've copied the two files from AGI into a "resources" folder here. The raw version looks good to me.

[archaeogeek]

Similarly I can confirm that referring to a local copy (eg in the same folder as the schematron files) in GeoNetwork solves the validation issue. I'll switch to using (eg) https://raw.githubusercontent.com/agiorguk/gemini-schematron/main/resources/MD_CharacterSetCode.xml and just double check but I don't foresee a problem