INSPIRE link in Element 37 Spatial data service type

[PeterParslow]

Guidance section:

Link should perhaps be to the "new" web versions of the INSPIRE TG rather than the older PDF version, e.g. https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139 or https://github.com/INSPIRE-MIF/technical-guidelines/blob/2022.2/metadata/metadata-iso19139/metadata-iso19139.adoc rather than https://inspire.ec.europa.eu/documents/inspire-metadata-implementing-rules-technical-guidelines-based-en-iso-19115-and-en-iso-1

Encoding:

The INSPIRE TG now gives an example using codeSpace to indicate the controlled list:

view This is because ISO 19139 implements LocalName using gml:CodeType, so it is not possible to use gmx:Anchor as you could with a gco:CharacterString. Note: the example in the INSPIRE Guidance is incorrect, it should be "LocalName" as shown in TG Requirement 3.5 just above; see https://github.com/INSPIRE-MIF/technical-guidelines/pull/71

[PeterParslow]

Not just an example, it's TG Requirement 3.5 which was already in the 2016 & 2017 TGs

[nmtoken]

https://inspire.ec.europa.eu/id/document/tg/metadata-iso19139 seems better as through the Document URL link it gives access to the three variants/formats of the documentation

AsciiDoc HTML PDF

[nmtoken]

The schematron rule MI-37a (Spatial Data Service Type) checks for content at path srv:serviceType/*[1] for 'view', 'download' etc. so strictly would allow either gco:LocalName or gco:ScopedName (neither gco:CharacterString or gmx:Anchor are allowed here by the schema).

Should the rule be tightened to check content at srv:serviceType/gco:LocalName or should a new rule be added to check that srv:serviceType/gco:LocalName exists.

[PeterParslow]

"localname" capitalisation fix now applied at INSPIRE MIF: https://github.com/INSPIRE-MIF/technical-guidelines/tree/2023.1