agiorguk / gemini-schematron

The Schematron files to support GEMINI 2.3 validation
0 stars 1 forks source link

Overzealous supplementary rule? "Gemini2-mi17-refSysInfo-recs" #4

Open archaeogeek opened 3 years ago

archaeogeek commented 3 years ago

Issue by PeterParslow Tue Aug 18 10:32:49 2020 Originally opened as https://github.com/AGIuk/Schematron/issues/3


This rule fires for any SRS that isn't in the INSPIRE default list. Perhaps it should only check the first one?

In fact, perhaps that's what the [1]s are trying to achieve?

Should the context in line 57, "//gmd:MD_Metadata[1]/gmd:referenceSystemInfo/[1]/gmd:referenceSystemIdentifier/gmd:RS_Identifier[1]/gmd:code/gmx:Anchor[1]/@xlink:href", actually be "//gmd:MD_Metadata[1]/gmd:referenceSystemInfo[1]//gmd:referenceSystemIdentifier/gmd:RS_Identifier[1]/gmd:code/gmx:Anchor[1]/@xlink:href"

(& even the other [1]s be on the roles, not the objects?)

Also (so perhaps a second issues), surely INSPIRE TG Requirement 2.2: metadata/2.0/req/isdss/crs-id states that the default CRSs shall be in the text of the element,

So perhaps this rule should move to the other Schematron file? But only if it's generalised to check the text regardless of whether it's an Anchor or a CharacterString, i.e. 4a in that harder rule would check gmx:Anchor not gmx:Anchor/@xlink:href

See discussion mainly in Bug Tracker Google doc

PeterParslow commented 3 years ago

Raised from old 2020-21:

Jo: “The guidance at https://www.agi.org.uk/40-gemini/1063-gemini-services#17 seems to suggest that for inspire compliance, at least one of the referenced CRS should be from the inspire default list, which is fine. However it also suggests that other reference systems can also be used. These trigger a validation warning from the supplemental schematron though, triggered by https://github.com/AGIGemini/Schematron/blob/master/GEMINI_2.3_supplemental-v1.0.sch#L53-L69

Note: Jo’s context is work to enable GEMINI 2.3 on the Scottish SDI

JP, we can change the rule so it is informational rather than warning for all records (or delete the check). My preference would be to keep the check for all records to guide providers to use HTTP URIs over URNs, as the INSPIRe direction of travel. For service records we can add a count and flag (it can only be a warning) that none of the identifiers match the default HTTP-URI identifiers.

Peter: Is it that the [1] in the context statement is in the wrong place? context="//gmd:MD_Metadata[1]/gmd:referenceSystemInfo/[1]/gmd:referenceSystemIdentifier/gmd:RS_Identifier[1]/gmd:code/gmx:Anchor[1]/@xlink:href"> Surely the repeating pattern is at the role (lower camel case) level, not at the object (upper camel case) level? So it would be context="//gmd:MD_Metadata[1]/gmd:referenceSystemInfo[1]//gmd:referenceSystemIdentifier/gmd:RS_Identifier[1]/gmd:code/gmx:Anchor[1]/@xlink:href"> & perhaps the other [1]s are wrong too?

And we should probably mention that we expect / need the INSPIRE one to be listed first, even though that’s not an explicit INSPIRE requirement.

JP: I don’t think a listing order is needed or particularly useful, may require tool rewrites.