search

agiorguk / gemini-schematron

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

[CLOSED] Update the check 'AT-6: Free text elements should not be empty' to allow empty values with the container element having a gco:nilReason attribute #2

Closed archaeogeek closed 3 years ago

archaeogeek commented 3 years ago

Issue by josegar74 Fri Feb 28 09:51:48 2020 Originally opened as https://github.com/AGIuk/Schematron/pull/1

With this change, elements like these validate also:

  <gmd:individualName gco:nilReason="missing">
    <gco:CharacterString></gco:CharacterString>
  </gmd:individualName>

josegar74 included the following code: https://github.com/AGIuk/Schematron/pull/1/commits

archaeogeek commented 3 years ago

Comment by PeterParslow Fri Feb 28 11:48:38 2020

I'm don't think XML like that should validate. The general GEMINI XML encoding guidance (https://www.agi.org.uk/40-gemini/1048-uk-gemini-encoding-guidance#2.2, 2.2.10) says "Empty XML elements are not permitted in ISO 19139 metadata instances." This hasn't changed since the Defra/UK Location GEMINI Encoding Guidance of 2012 (possibly even 2010) - but I do believe it's always been a bit of a problem for GeoNetwork.

This expresses our understanding of ISO 19139:2007 Clause 9.7.3.4, which says "The gco:nilReason XML attribute manages null values in an XML instance document. At the property level, this attribute allows a reason (explaining why the actual value cannot be provided) to exist in place of an actual value."

It derives this understanding from GML, where 8.2.3.1 states "gml:NilReasonType defines a content model that allows recording of an explanation for a void value or other exception."

Both suggests to me that the intention is that gco:nilReason (and gml:nilReason in that context) should only be present if the element has no child elements.

[Note build on the XML concept "nillable", although there (within 3.3.4.3 of https://www.w3.org/TR/xmlschema11-1/) it seems that an element which is nillable in the schema declaration and has no xsi:nil attribute in the instance might be valid whether or not it has contents.]

archaeogeek commented 3 years ago

Comment by PeterParslow Sat Feb 29 15:29:32 2020

That said, I do see in the INSPIRE Metadata TG there is an example which has a nilReason & then contents (p84):

although on p85 the same example continues with a second nilReason more the way I would expect: - although here the example doesn't actually line up with Recommendation 21 which is specific to that element, which reduces my confidence in the example.
archaeogeek commented 3 years ago

Comment by PeterParslow Tue Apr 28 10:40:58 2020

@josegar74: do you have any response to my comments on your pull request?

archaeogeek commented 3 years ago

Comment by archaeogeek Fri May 1 08:30:14 2020

Since @josegar74 submitted the pull request for me, I can probably answer on his behalf :-) The pull request was made in response to some core geonetwork behaviour in that if these elements aren't expanded to include an empty string then they can't be shown in the editor. People may think they are not present at all, and won't be able to easily add values if they wish (without editing the xml directly). Having said that, I believe we have a work around now which expands elements and then strips them back again before validation. If the general feeling is that this change violates the rules then unless @josegar74 objects, I'm happy for the PR to be closed without being accepted.

archaeogeek commented 3 years ago

Comment by nmtoken Fri May 1 09:43:33 2020

I agree with @PeterParslow that the pull request breaks the intention of the specification(s) and should not be accepted.

archaeogeek commented 3 years ago

Comment by archaeogeek Fri May 1 10:14:28 2020

Happy to close it