Apologies for bumping this thread, but I figured I might catch someone’s eyes by sending an update at a different time. As per my previous email, I have records working in iso19139, but not in my custom schema, iso19139.MERIDIAN - and I can’t even seem to forcibly switch to iso19139’s labels or strings when using records in my schema. It’s almost like the xslt files fail to load labels and strings - despite them existing and working properly in the metadata record and editor itself. I’m wondering whether someone might understand this problem better than me or possibly have insight on how to resolve it.
···
From: Kim Mortimer
Sent: 05 April 2019 16:34
To: Francois Prunayre; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Editor validation fails quietly
Hi all,
I wanted to send an update and new question based on my experimentation today. I tried a number of things and confirmed that the variable metadataSchema was being read correctly for our schema. I also confirmed that records in iso19139 have functioning geonet:parse-xsd-error outputs on our server. Thus, it appears records in iso19139 have a non-empty sequence in “/root/*[name() = $metadataSchema]/labels”. Knowing that, I changed the parse-xsd-error function to always point to iso19139 -
<xsl:value-of select="geonet:parse-xsd-error(geonet:message,
‘iso19139’,
/root/*[name() =‘iso19139’]/labels,
/root/*[name() = ‘iso19139’]/strings)"/>
This works correctly when the record is in iso19139, but does not work for records in our schema (iso19139.MERIDIAN).
Thus when the record is iso19139, validate.xsl:
-
handles /root/*[name() =$metdataSchema]/labels
-
handles /root/*[name() =‘iso19139’]/labels
-
doesn’t work if I set the name to something weird (e.g., /root/*[name() =‘#N/A’]/labels)
But when the record is iso19139.MERIDIAN, validate.xsl :
-
doesn’t handle /root/*[name() =$metdataSchema]/labels (even though $metadataSchema is non-empty and equal to iso19139.MERIDIAN)
-
doesn’t handle /root/[name() =‘iso19139’]/labels
My interpretation of this is that validate.xsl is called by something which dynamically fills /root/ with things, and then /root/ is emptied. Otherwise, iso19139.MERIDIAN with /root/[name() =‘iso19139’]/labels seems like it should work (at least for things that have labels in iso19139).
I had been under the impression that once GeoNetwork was ‘built’ and running, these sorts of things were static. Can anyone explain this? Or possibly point to how/where the /root/iso19139/labels is populated (and seemingly removed later)?
Thanks very much,
Kim
From: Kim Mortimer K.Mortimer@anonymised.com
Sent: 04 April 2019 15:48
To: Francois Prunayre; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Editor validation fails quietly
Sorry for the rapid succession of emails - I remembered what worked in the past and have confirmed it. The Schematron validation reports work as expected - e.g., if certain elements are missing then I get a notification complete with red thumbs down and a message pulled from strings. But if there is a schema error (which is, I believe, the part entirely handled by the xsdErrors template) then the entire validation box goes blank - presumably because the template generating the entire validation box stops here https://github.com/geonetwork/core-geonetwork/blob/3.4.x/web/src/main/webapp/xslt/services/metadata/validate.xsl#L81 after being unable to completely parse xsdErrors.
Which I believe still implies something with this statement: " /root/*[name() = $metadataSchema]/labels" is invalid, or perhaps empty.
Again apologies,
Kim
From: Kim Mortimer K.Mortimer@anonymised.com
Sent: 04 April 2019 15:29
To: Francois Prunayre; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Editor validation fails quietly
Maybe I spoke too soon here or got confused with another record as I’ve been unable to reproduce this since sending this email… It’s almost like the variable metadataSchema from https://github.com/geonetwork/core-geonetwork/blob/3.4.x/web/src/main/webapp/xslt/services/metadata/validate.xsl isn’t being read properly?
Kim
From: Kim Mortimer K.Mortimer@anonymised.com
Sent: 04 April 2019 10:59
To: Francois Prunayre; geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Editor validation fails quietly
Hi all,
I felt the need to correct my previous email. I was doing some more testing this week and noticed that validation appears to work normally - including errors - when working with elements contained in the core ISO 19139 schema. The tests I was referring to involved editing Darwin Core fields, which have types such as xs:double and dwc:NonEmptyString. Modifying these fields to be invalid (making an empty or text xs:double, or an empty dwc:NonEmptyString) causes the empty validator - which comes back after correcting the error or removing the field.
Given Francois’ response, my current guess is that these types are throwing XSD errors which are not handled by the default strings.xml. I’ll look into this idea more myself.
If this sounds familiar to someone else’s problem, feel free to let me know - maybe this has already been solved.
Thanks,
Kim
From: Kim Mortimer
Sent: 01 April 2019 10:23
To: Francois Prunayre
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Editor validation fails quietly
Hi Francois,
Thank you for your reply and suggestion. I can confirm that our strings.xml contains contains all of the XSD messages listed there. It is in fact a copy of that file plus a few additions which I added in response to previous log files. They have unique names and do not overlap with the XSD messages.
Kim
From: Francois Prunayre fx.prunayre@anonymised.com
Sent: 29 March 2019 17:26
To: Kim Mortimer
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] Editor validation fails quietly
Hi,
Le ven. 29 mars 2019 à 20:41, Kim Mortimer <K.Mortimer@anonymised.com> a écrit :
Hi all,
Thankfully, I’ve managed to resolve (most of) the button issues from my previous emails. This is only tangentially related…
With my plugin now mostly working, I’ve been testing out the editor and checking for missing labels, bugs, etc. The test file I use validates against the schema and two different schematron files. If I modify my sample file to be invalid in the editor (e.g., replace a number with text), I would expect the validate button to report what was wrong. Instead, if there is a problem with my file, I get an empty “validate” box. In the logs, I see
“Error on line 108 of validate.xsl:
XTTE0790: An empty sequence is not allowed as the third argument of geonet:parse-xsd-error()”
(https://github.com/geonetwork/core-geonetwork/blob/3.4.x/web/src/main/webapp/xslt/services/metadata/validate.xsl)
which implies there is some sort of label missing.
Could you check that your plugin provides a strings.xml file with at least the translation keys needed for XSD messages ?
https://github.com/geonetwork/core-geonetwork/blob/3.4.x/schemas/iso19139/src/main/plugin/iso19139/loc/eng/strings.xml#L72-L85
HTH
Francois
However, there are no messages in the logs about missing translations, which I’ve typically received when an element was missing a label before. As such, I’m unsure where to even begin.
I’ve already added labels for all the elements and codelists I’ve added to the core ISO 19139 plugin, and even labelled the datatypes present in my extensions - with a few exceptions. I’m using Darwin Core in my plugin and most of the elements there have types like xs:double, but I can’t add those to labels.xml without GeoNetwork complaining that the xs namespace is not declared (despite it being declared).
Does anyone here have any thoughts or ideas on how to fix this validator issue?
Thanks in advance,
Kim
|
Kim Mortimer
|
|
Data Manager
|
|
MERIDIAN - Marine Environmental Research Infrastructure for Data Integration and Application Network
|
|
Institute for Big Data Analytics, Faculty of Computer Sciences, Dalhousie University
|
|
p: + 1 902 494 1812 m: +1 902 880 1863
|
|
a: 6050 University Ave, Halifax, NS, B3H 4R2, Canada
|
|
w: https://meridian.cs.dal.ca e: k.mortimer@anonymised.com
|
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
