[GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi there,

I’ve been working on an ISO 19139 and ISO 19139-2 based plugin for GeoNetwork as part of my work at MERIDIAN. It’s fairly far along now but there’s one issue that I haven’t been able to figure out - how GeoNetwork manages and creates the buttons for adding empty optional or repeated fields.

I took a screenshot recently which compares our sample record (on the left) to one of the built-in ISO 19139 sample records (Hydrological basins in Africa, on the right). You can view it here - https://imgur.com/a/AefHcHn - and note how buttons for adding, e.g., Alternate Title, Citation identifier, do not appear in our record (on the left). Both are using the same view mode and have many similarities otherwise, as my plugin is mostly an adaptation of the default ISO 19139 plugin.

My understanding of GeoNetwork is that these buttons are created by calling the “render-element-to-add” XSLT template, which appear in the layout/layout.xsl file. However, I don’t understand why the rest of the editor seems to render fine but these templates do not.

Since this is an ISO 19139-2 based profile, the root element is changed from gmd:MD_Metadata to gmi:MI_Metadata, and we have extended gmd:MD_DataIdentification using a custom namespace into MER:MD_DataIdentification (with label MERIDIAN DataIdentification). All the elements inside CI_Citation are unchanged - including their conditionality - and use the same schemas as the default GeoNetwork ISO 19139 plugin, so I struggle to understand what is causing this problem. I hope someone else on this mailing list who is more familiar with GeoNetwork and the creation of plugins might recognize this problem or have an idea on how to solve it. (There are also no changes to the list of flatModeExceptions)

I would be happy to provide further information (e.g., plugin files) upon request.

Thank you very much for your time,

Kim Mortimer

Data Manager @ MERIDIAN

···

MERIDIAN on blue circle containing many numbers, with an orange wave pulse to the right.

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

Hello Kim,

First you have to add the field "alternateTitle" to your
/modelo/my_model.xml: <gmd: alternateTitle gco: nilReason = "missing" />.
Without this the field will not be displayed on your form.

Change the cardinality of your "alternateTitle" field through the
"maxOccurs" property, change the value to "unbounded". That way you can add
as many alternative Titles as you want. Do this in the file
/schema/gmd/citation.xsd

Add the <for name = "gmd: alternateTitle" /> inside the "flatModeExceptions"
tag in the /layout/config-editor.xml file

What model are you using, inspire_sds, service?

--
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoNetwork-developer-f3874395.html

Hi Tatau,

To further clarify: We are using the same GMD schema as available from the ISO 19115/ISO 19139 core plugin - we already have alternateTitle with maxOccurs=“unbounded”.

I am unsure why you are suggesting adding alternateTitle to the flatModeExceptions when this isn’t done in the core ISO 19115/ISO 19139 core plugin. I feel like this will make us less like the core ISO 19115/ISO 19139 plugin, not more.

I am not 100% sure what you mean by your first paragraph and your last question. I presume in the first paragraph you mean adding <gmd: alternateTitle gco: nilReason = “missing” /> to our sample file at an appropriate location? This is not present in the other sample file I show, so it seems that would be unnecessary.

As to your last question - again, I’m not 100% sure what you mean, but this is an ISO 19115-2 / ISO 19139-2 data object with a modified MD_DataIdentification to allow insertion of Darwin Core. It is neither an INSPIRE nor a service object. The xpath for the shown section would be gmi:MI_Metadata/gmd:identificationInformation/MER:MD_DataIdentification/gmd:citation/gmd:CI_Citation/. MER:MD_DataIdentification is just an extension of gmd:MD_DataIdentification with gco:isoType=“gmd:MD_DataIdentification” and the previously mentioned Darwin Core record set.

Happy to have a response and hopefully these add to your understanding of my issue.

Thanks,

Kim

···

From: tatau tarcisio.saraujo@anonymised.com
Sent: 14 March 2019 14:54:52
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hello Kim,

First you have to add the field “alternateTitle” to your
/modelo/my_model.xml: <gmd: alternateTitle gco: nilReason = “missing” />.
Without this the field will not be displayed on your form.

Change the cardinality of your “alternateTitle” field through the
“maxOccurs” property, change the value to “unbounded”. That way you can add
as many alternative Titles as you want. Do this in the file
/schema/gmd/citation.xsd

Add the inside the “flatModeExceptions”
tag in the /layout/config-editor.xml file

What model are you using, inspire_sds, service?


Sent from: http://osgeo-org.1560.x6.nabble.com/GeoNetwork-developer-f3874395.html


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

Hi Kim,

Le jeu. 14 mars 2019 à 15:50, Kim Mortimer <K.Mortimer@anonymised.com> a écrit :

Hi there,

I’ve been working on an ISO 19139 and ISO 19139-2 based plugin for GeoNetwork as part of my work at MERIDIAN. It’s fairly far along now but there’s one issue that I haven’t been able to figure out - how GeoNetwork manages and creates the buttons for adding empty optional or repeated fields.

This is based on the XSD you provide as entry point to your plugin.

I took a screenshot recently which compares our sample record (on the left) to one of the built-in ISO 19139 sample records (Hydrological basins in Africa, on the right). You can view it here - https://imgur.com/a/AefHcHn - and note how buttons for adding, e.g., Alternate Title, Citation identifier, do not appear in our record (on the left). Both are using the same view mode and have many similarities otherwise, as my plugin is mostly an adaptation of the default ISO 19139 plugin.

From you screenshot, it looks like the advanced view only render information that are in your XML input. So I would suspect that GeoNetwork did not manage to load your schema properly. Any errors/warning on startup ?

My understanding of GeoNetwork is that these buttons are created by calling the “render-element-to-add” XSLT template, which appear in the layout/layout.xsl file. However, I don’t understand why the rest of the editor seems to render fine but these templates do not.

The editor is built from the combination of your XML + XSD. This creates a “metadocument” which is then processed by layout.xsl. Have a look to the document before XSL processsing to see if your XSD info are correctly available in it. See
https://github.com/geonetwork/core-geonetwork/blob/master/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L707-L747

Since this is an ISO 19139-2 based profile, the root element is changed from gmd:MD_Metadata to gmi:MI_Metadata, and we have extended gmd:MD_DataIdentification using a custom namespace into MER:MD_DataIdentification (with label MERIDIAN DataIdentification). All the elements inside CI_Citation are unchanged - including their conditionality - and use the same schemas as the default GeoNetwork ISO 19139 plugin, so I struggle to understand what is causing this problem. I hope someone else on this mailing list who is more familiar with GeoNetwork and the creation of plugins might recognize this problem or have an idea on how to solve it. (There are also no changes to the list of flatModeExceptions)

FYI, 115-2 standard for imagery will be supported in https://github.com/metadata101/iso19115-3.2018 but this is still work in progress.

HTH

Francois

I would be happy to provide further information (e.g., plugin files) upon request.

Thank you very much for your time,

Kim Mortimer

Data Manager @ MERIDIAN

MERIDIAN on blue circle containing many numbers, with an orange wave pulse to the right.

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

Hello Kim,

Disregard my answer. It definitely does not have anything to do with the
problem you are experiencing. Excuse me.

It seems to me that it is a problem that I will also face soon in my work.

Thank you Francois

--
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoNetwork-developer-f3874395.html

Hi Francois,

Thank you for your reply.

Regarding the screenshot and rendering - yes, that is my interpretation as well. We get a few warnings during build (about the pom package and the npm package) but nothing specific to our plugin. We do get some warnings in the logs - some of which, from my understanding, are known issues in GeoNetwork 3.4.4.0 - but they also do not appear specific to our plugin. I have asked my colleague who manages the Java and server side to look into the pom and npm warnings.

Regarding your comment “Have a look to the document before XSL processsing to see if your XSD info are correctly available in it” - I am not sure if I understand what you mean here. It sounds like you mean looking at the intermediate ‘editor’ ‘xml’ before it’s passed to layout.xsl? I have to admit I am not sure I know how to do that, but I can investigate further. Clarification or suggestions would be appreciated!

I’m looking forward to the eventual ISO 19115-3 plugin, and hope I can contribute to it in some way - as noted we’re currently working with the previous ‘generation’ of ISO XML schemas, but we intend to eventually migrate to ISO 19115-3 ourselves.

Thanks very much for your support,

Kim

···

From: Francois Prunayre fx.prunayre@anonymised.com
Sent: 15 March 2019 07:24:14
To: Kim Mortimer
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Kim,

Le jeu. 14 mars 2019 à 15:50, Kim Mortimer <K.Mortimer@anonymised.com> a écrit :

Hi there,

I’ve been working on an ISO 19139 and ISO 19139-2 based plugin for GeoNetwork as part of my work at MERIDIAN. It’s fairly far along now but there’s one issue that I haven’t been able to figure out - how GeoNetwork manages and creates the buttons for adding empty optional or repeated fields.

This is based on the XSD you provide as entry point to your plugin.

I took a screenshot recently which compares our sample record (on the left) to one of the built-in ISO 19139 sample records (Hydrological basins in Africa, on the right). You can view it here - https://imgur.com/a/AefHcHn - and note how buttons for adding, e.g., Alternate Title, Citation identifier, do not appear in our record (on the left). Both are using the same view mode and have many similarities otherwise, as my plugin is mostly an adaptation of the default ISO 19139 plugin.

From you screenshot, it looks like the advanced view only render information that are in your XML input. So I would suspect that GeoNetwork did not manage to load your schema properly. Any errors/warning on startup ?

My understanding of GeoNetwork is that these buttons are created by calling the “render-element-to-add” XSLT template, which appear in the layout/layout.xsl file. However, I don’t understand why the rest of the editor seems to render fine but these templates do not.

The editor is built from the combination of your XML + XSD. This creates a “metadocument” which is then processed by layout.xsl. Have a look to the document before XSL processsing to see if your XSD info are correctly available in it. See
https://github.com/geonetwork/core-geonetwork/blob/master/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L707-L747

Since this is an ISO 19139-2 based profile, the root element is changed from gmd:MD_Metadata to gmi:MI_Metadata, and we have extended gmd:MD_DataIdentification using a custom namespace into MER:MD_DataIdentification (with label MERIDIAN DataIdentification). All the elements inside CI_Citation are unchanged - including their conditionality - and use the same schemas as the default GeoNetwork ISO 19139 plugin, so I struggle to understand what is causing this problem. I hope someone else on this mailing list who is more familiar with GeoNetwork and the creation of plugins might recognize this problem or have an idea on how to solve it. (There are also no changes to the list of flatModeExceptions)

FYI, 115-2 standard for imagery will be supported in https://github.com/metadata101/iso19115-3.2018 but this is still work in progress.

HTH

Francois

I would be happy to provide further information (e.g., plugin files) upon request.

Thank you very much for your time,

Kim Mortimer

Data Manager @ MERIDIAN

MERIDIAN on blue circle containing many numbers, with an orange wave pulse to the right.

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

Hi all,

Just following up to see whether anyone else might be able to offer advice or assist with this - I’m feeling well and truly stuck! The key elements of the layout folder are basically just copies from the core ISO 19139 plugin with namespaces (and elements) updated where appropriate. Our config-editor.xml contains plenty of “<action type=“add” … >” statements with correct paths for “in”, yet these don’t appear on the editor. In fact, it seems fields only appear in the editor when they already have content in them in the ‘source’…

It feels like, for some reason, something is ‘fixed’ to “gmd:MD_Metadata” in the rendering - or alternatively in ISO 19139 mode instead of our custom mode - yet there are no errors in the logs, no validation errors, no build errors… and yet I know that my files are being read, because the additional tabs I added appear and their content is visible.

Any ideas, suggestions, advice, assistance… etc., etc., would be greatly appreciated. Alternatively ‘poking my nose’ into the XML processing of GeoNetwork’s editor as it runs might give me a hint, but I’m afraid I don’t know how to do that - again, suggestions welcome.

Thanks very much,

Kim

···

From: Kim Mortimer
Sent: 15 March 2019 11:38:17
To: Francois Prunayre
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Francois,

Thank you for your reply.

Regarding the screenshot and rendering - yes, that is my interpretation as well. We get a few warnings during build (about the pom package and the npm package) but nothing specific to our plugin. We do get some warnings in the logs - some of which, from my understanding, are known issues in GeoNetwork 3.4.4.0 - but they also do not appear specific to our plugin. I have asked my colleague who manages the Java and server side to look into the pom and npm warnings.

Regarding your comment “Have a look to the document before XSL processsing to see if your XSD info are correctly available in it” - I am not sure if I understand what you mean here. It sounds like you mean looking at the intermediate ‘editor’ ‘xml’ before it’s passed to layout.xsl? I have to admit I am not sure I know how to do that, but I can investigate further. Clarification or suggestions would be appreciated!

I’m looking forward to the eventual ISO 19115-3 plugin, and hope I can contribute to it in some way - as noted we’re currently working with the previous ‘generation’ of ISO XML schemas, but we intend to eventually migrate to ISO 19115-3 ourselves.

Thanks very much for your support,

Kim

From: Francois Prunayre fx.prunayre@anonymised.com
Sent: 15 March 2019 07:24:14
To: Kim Mortimer
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Kim,

Le jeu. 14 mars 2019 à 15:50, Kim Mortimer <K.Mortimer@anonymised.com> a écrit :

Hi there,

I’ve been working on an ISO 19139 and ISO 19139-2 based plugin for GeoNetwork as part of my work at MERIDIAN. It’s fairly far along now but there’s one issue that I haven’t been able to figure out - how GeoNetwork manages and creates the buttons for adding empty optional or repeated fields.

This is based on the XSD you provide as entry point to your plugin.

I took a screenshot recently which compares our sample record (on the left) to one of the built-in ISO 19139 sample records (Hydrological basins in Africa, on the right). You can view it here - https://imgur.com/a/AefHcHn - and note how buttons for adding, e.g., Alternate Title, Citation identifier, do not appear in our record (on the left). Both are using the same view mode and have many similarities otherwise, as my plugin is mostly an adaptation of the default ISO 19139 plugin.

From you screenshot, it looks like the advanced view only render information that are in your XML input. So I would suspect that GeoNetwork did not manage to load your schema properly. Any errors/warning on startup ?

My understanding of GeoNetwork is that these buttons are created by calling the “render-element-to-add” XSLT template, which appear in the layout/layout.xsl file. However, I don’t understand why the rest of the editor seems to render fine but these templates do not.

The editor is built from the combination of your XML + XSD. This creates a “metadocument” which is then processed by layout.xsl. Have a look to the document before XSL processsing to see if your XSD info are correctly available in it. See
https://github.com/geonetwork/core-geonetwork/blob/master/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L707-L747

Since this is an ISO 19139-2 based profile, the root element is changed from gmd:MD_Metadata to gmi:MI_Metadata, and we have extended gmd:MD_DataIdentification using a custom namespace into MER:MD_DataIdentification (with label MERIDIAN DataIdentification). All the elements inside CI_Citation are unchanged - including their conditionality - and use the same schemas as the default GeoNetwork ISO 19139 plugin, so I struggle to understand what is causing this problem. I hope someone else on this mailing list who is more familiar with GeoNetwork and the creation of plugins might recognize this problem or have an idea on how to solve it. (There are also no changes to the list of flatModeExceptions)

FYI, 115-2 standard for imagery will be supported in https://github.com/metadata101/iso19115-3.2018 but this is still work in progress.

HTH

Francois

I would be happy to provide further information (e.g., plugin files) upon request.

Thank you very much for your time,

Kim Mortimer

Data Manager @ MERIDIAN

MERIDIAN on blue circle containing many numbers, with an orange wave pulse to the right.

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


Hi all,

Just a follow up from me. My coworker managed to dig into the code and pulled out some intermediate XML. This led me to notice I had a template + match statement (which I borrowed from Dublin Core to allow us to use Darwin Core) which was duplicated. After that and a few more small changes, I’ve managed to get buttons appearing on all pages and in their correct spots, which is a significant improvement from Wednesday.

However, most buttons (seemingly all text elements?) don’t appear to know whether they are codelists or text. They seem to offer the ability for me to select any codelist in my schema, along with text, resulting in a very long dropdown menu. However, even though it is reading the name of each element in the button’s dropdown from my labels.xml file, it isn’t syncing up correctly with codelists.xml, so selecting some of those just results in a free-text field anyways…

I assume I’ll need to dig into the layout folder for mismatched references to gco:CharacterString, but I thought I would update the mailing list and see whether this seemed similar to problems previous plugin creators faced.

Thanks very much,

Kim

···

From: Kim Mortimer K.Mortimer@anonymised.com
Sent: 20 March 2019 17:27:36
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi all,

Just following up to see whether anyone else might be able to offer advice or assist with this - I’m feeling well and truly stuck! The key elements of the layout folder are basically just copies from the core ISO 19139 plugin with namespaces (and elements) updated where appropriate. Our config-editor.xml contains plenty of “<action type=“add” … >” statements with correct paths for “in”, yet these don’t appear on the editor. In fact, it seems fields only appear in the editor when they already have content in them in the ‘source’…

It feels like, for some reason, something is ‘fixed’ to “gmd:MD_Metadata” in the rendering - or alternatively in ISO 19139 mode instead of our custom mode - yet there are no errors in the logs, no validation errors, no build errors… and yet I know that my files are being read, because the additional tabs I added appear and their content is visible.

Any ideas, suggestions, advice, assistance… etc., etc., would be greatly appreciated. Alternatively ‘poking my nose’ into the XML processing of GeoNetwork’s editor as it runs might give me a hint, but I’m afraid I don’t know how to do that - again, suggestions welcome.

Thanks very much,

Kim

From: Kim Mortimer
Sent: 15 March 2019 11:38:17
To: Francois Prunayre
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Francois,

Thank you for your reply.

Regarding the screenshot and rendering - yes, that is my interpretation as well. We get a few warnings during build (about the pom package and the npm package) but nothing specific to our plugin. We do get some warnings in the logs - some of which, from my understanding, are known issues in GeoNetwork 3.4.4.0 - but they also do not appear specific to our plugin. I have asked my colleague who manages the Java and server side to look into the pom and npm warnings.

Regarding your comment “Have a look to the document before XSL processsing to see if your XSD info are correctly available in it” - I am not sure if I understand what you mean here. It sounds like you mean looking at the intermediate ‘editor’ ‘xml’ before it’s passed to layout.xsl? I have to admit I am not sure I know how to do that, but I can investigate further. Clarification or suggestions would be appreciated!

I’m looking forward to the eventual ISO 19115-3 plugin, and hope I can contribute to it in some way - as noted we’re currently working with the previous ‘generation’ of ISO XML schemas, but we intend to eventually migrate to ISO 19115-3 ourselves.

Thanks very much for your support,

Kim

From: Francois Prunayre fx.prunayre@anonymised.com
Sent: 15 March 2019 07:24:14
To: Kim Mortimer
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Kim,

Le jeu. 14 mars 2019 à 15:50, Kim Mortimer <K.Mortimer@anonymised.com> a écrit :

Hi there,

I’ve been working on an ISO 19139 and ISO 19139-2 based plugin for GeoNetwork as part of my work at MERIDIAN. It’s fairly far along now but there’s one issue that I haven’t been able to figure out - how GeoNetwork manages and creates the buttons for adding empty optional or repeated fields.

This is based on the XSD you provide as entry point to your plugin.

I took a screenshot recently which compares our sample record (on the left) to one of the built-in ISO 19139 sample records (Hydrological basins in Africa, on the right). You can view it here - https://imgur.com/a/AefHcHn - and note how buttons for adding, e.g., Alternate Title, Citation identifier, do not appear in our record (on the left). Both are using the same view mode and have many similarities otherwise, as my plugin is mostly an adaptation of the default ISO 19139 plugin.

From you screenshot, it looks like the advanced view only render information that are in your XML input. So I would suspect that GeoNetwork did not manage to load your schema properly. Any errors/warning on startup ?

My understanding of GeoNetwork is that these buttons are created by calling the “render-element-to-add” XSLT template, which appear in the layout/layout.xsl file. However, I don’t understand why the rest of the editor seems to render fine but these templates do not.

The editor is built from the combination of your XML + XSD. This creates a “metadocument” which is then processed by layout.xsl. Have a look to the document before XSL processsing to see if your XSD info are correctly available in it. See
https://github.com/geonetwork/core-geonetwork/blob/master/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L707-L747

Since this is an ISO 19139-2 based profile, the root element is changed from gmd:MD_Metadata to gmi:MI_Metadata, and we have extended gmd:MD_DataIdentification using a custom namespace into MER:MD_DataIdentification (with label MERIDIAN DataIdentification). All the elements inside CI_Citation are unchanged - including their conditionality - and use the same schemas as the default GeoNetwork ISO 19139 plugin, so I struggle to understand what is causing this problem. I hope someone else on this mailing list who is more familiar with GeoNetwork and the creation of plugins might recognize this problem or have an idea on how to solve it. (There are also no changes to the list of flatModeExceptions)

FYI, 115-2 standard for imagery will be supported in https://github.com/metadata101/iso19115-3.2018 but this is still work in progress.

HTH

Francois

I would be happy to provide further information (e.g., plugin files) upon request.

Thank you very much for your time,

Kim Mortimer

Data Manager @ MERIDIAN

MERIDIAN on blue circle containing many numbers, with an orange wave pulse to the right.

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



Apologies for the continued emails - given this may assist someone else in the group I figured I would send another update.

Doing some more digging I realized all the elements in the text button dropdown were in the gco:CharacterString substitution group, and GeoNetwork was showing me all the available substitutions. From digging into the Java, I learned about EditLib.java and the isOrType function which seemed to be failing. (e.g., as in https://github.com/geonetwork/core-geonetwork/blob/3.4.x/core/src/main/java/org/fao/geonet/kernel/EditLib.java#L1848)

I’m not sure exactly why this section isn’t being tripped. There are no relevant suggestions (it’s functionally identical to core iso19139 suggestions), the list of valid entry types for the buttons include gco:CharacterString (which is identical to our getBasicTypeCharacterStringName), and our plugin implements ISOPlugin. As such, I am very confused why our text fields are not satisfying EditLib’s requirements to substitute only gco:CharacterString. My only guess so far is that .getElementList().contains() may not be a valid piece of Java in our environment.

I would appreciate any suggestions or ideas that anyone may have.

Thanks very much,

···

From: Kim Mortimer K.Mortimer@anonymised.com
Sent: 22 March 2019 16:10:22
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi all,

Just a follow up from me. My coworker managed to dig into the code and pulled out some intermediate XML. This led me to notice I had a template + match statement (which I borrowed from Dublin Core to allow us to use Darwin Core) which was duplicated. After that and a few more small changes, I’ve managed to get buttons appearing on all pages and in their correct spots, which is a significant improvement from Wednesday.

However, most buttons (seemingly all text elements?) don’t appear to know whether they are codelists or text. They seem to offer the ability for me to select any codelist in my schema, along with text, resulting in a very long dropdown menu. However, even though it is reading the name of each element in the button’s dropdown from my labels.xml file, it isn’t syncing up correctly with codelists.xml, so selecting some of those just results in a free-text field anyways…

I assume I’ll need to dig into the layout folder for mismatched references to gco:CharacterString, but I thought I would update the mailing list and see whether this seemed similar to problems previous plugin creators faced.

Thanks very much,

Kim

From: Kim Mortimer K.Mortimer@anonymised.com
Sent: 20 March 2019 17:27:36
To: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi all,

Just following up to see whether anyone else might be able to offer advice or assist with this - I’m feeling well and truly stuck! The key elements of the layout folder are basically just copies from the core ISO 19139 plugin with namespaces (and elements) updated where appropriate. Our config-editor.xml contains plenty of “<action type=“add” … >” statements with correct paths for “in”, yet these don’t appear on the editor. In fact, it seems fields only appear in the editor when they already have content in them in the ‘source’…

It feels like, for some reason, something is ‘fixed’ to “gmd:MD_Metadata” in the rendering - or alternatively in ISO 19139 mode instead of our custom mode - yet there are no errors in the logs, no validation errors, no build errors… and yet I know that my files are being read, because the additional tabs I added appear and their content is visible.

Any ideas, suggestions, advice, assistance… etc., etc., would be greatly appreciated. Alternatively ‘poking my nose’ into the XML processing of GeoNetwork’s editor as it runs might give me a hint, but I’m afraid I don’t know how to do that - again, suggestions welcome.

Thanks very much,

Kim

From: Kim Mortimer
Sent: 15 March 2019 11:38:17
To: Francois Prunayre
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Francois,

Thank you for your reply.

Regarding the screenshot and rendering - yes, that is my interpretation as well. We get a few warnings during build (about the pom package and the npm package) but nothing specific to our plugin. We do get some warnings in the logs - some of which, from my understanding, are known issues in GeoNetwork 3.4.4.0 - but they also do not appear specific to our plugin. I have asked my colleague who manages the Java and server side to look into the pom and npm warnings.

Regarding your comment “Have a look to the document before XSL processsing to see if your XSD info are correctly available in it” - I am not sure if I understand what you mean here. It sounds like you mean looking at the intermediate ‘editor’ ‘xml’ before it’s passed to layout.xsl? I have to admit I am not sure I know how to do that, but I can investigate further. Clarification or suggestions would be appreciated!

I’m looking forward to the eventual ISO 19115-3 plugin, and hope I can contribute to it in some way - as noted we’re currently working with the previous ‘generation’ of ISO XML schemas, but we intend to eventually migrate to ISO 19115-3 ourselves.

Thanks very much for your support,

Kim

From: Francois Prunayre fx.prunayre@anonymised.com
Sent: 15 March 2019 07:24:14
To: Kim Mortimer
Cc: geonetwork-devel@lists.sourceforge.net
Subject: Re: [GeoNetwork-devel] ISO 19139-based plugins and editor buttons

Hi Kim,

Le jeu. 14 mars 2019 à 15:50, Kim Mortimer <K.Mortimer@anonymised.com> a écrit :

Hi there,

I’ve been working on an ISO 19139 and ISO 19139-2 based plugin for GeoNetwork as part of my work at MERIDIAN. It’s fairly far along now but there’s one issue that I haven’t been able to figure out - how GeoNetwork manages and creates the buttons for adding empty optional or repeated fields.

This is based on the XSD you provide as entry point to your plugin.

I took a screenshot recently which compares our sample record (on the left) to one of the built-in ISO 19139 sample records (Hydrological basins in Africa, on the right). You can view it here - https://imgur.com/a/AefHcHn - and note how buttons for adding, e.g., Alternate Title, Citation identifier, do not appear in our record (on the left). Both are using the same view mode and have many similarities otherwise, as my plugin is mostly an adaptation of the default ISO 19139 plugin.

From you screenshot, it looks like the advanced view only render information that are in your XML input. So I would suspect that GeoNetwork did not manage to load your schema properly. Any errors/warning on startup ?

My understanding of GeoNetwork is that these buttons are created by calling the “render-element-to-add” XSLT template, which appear in the layout/layout.xsl file. However, I don’t understand why the rest of the editor seems to render fine but these templates do not.

The editor is built from the combination of your XML + XSD. This creates a “metadocument” which is then processed by layout.xsl. Have a look to the document before XSL processsing to see if your XSD info are correctly available in it. See
https://github.com/geonetwork/core-geonetwork/blob/master/services/src/main/java/org/fao/geonet/api/records/editing/MetadataEditingApi.java#L707-L747

Since this is an ISO 19139-2 based profile, the root element is changed from gmd:MD_Metadata to gmi:MI_Metadata, and we have extended gmd:MD_DataIdentification using a custom namespace into MER:MD_DataIdentification (with label MERIDIAN DataIdentification). All the elements inside CI_Citation are unchanged - including their conditionality - and use the same schemas as the default GeoNetwork ISO 19139 plugin, so I struggle to understand what is causing this problem. I hope someone else on this mailing list who is more familiar with GeoNetwork and the creation of plugins might recognize this problem or have an idea on how to solve it. (There are also no changes to the list of flatModeExceptions)

FYI, 115-2 standard for imagery will be supported in https://github.com/metadata101/iso19115-3.2018 but this is still work in progress.

HTH

Francois

I would be happy to provide further information (e.g., plugin files) upon request.

Thank you very much for your time,

Kim Mortimer

Data Manager @ MERIDIAN

MERIDIAN on blue circle containing many numbers, with an orange wave pulse to the right.

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