Proposal title

Date	2010/09/07
Contact(s)	Simon Pigot
Last edited
Status	in progress
Assigned to release	2.7.x
Resources	Available

Overview

It should be possible to plug-in Metadata Schemas (including profiles). This means that a user/admin should be able to use a service to add a profile/schema to their existing GeoNetwork installation without having to make manual changes to config, Java code, xslts and javascript.

Proposal Type

• Type: Core Change
• App: GeoNetwork
• Module: Kernel, Data Manager

Links

• Documents:
• Email discussions:
• Other wiki discussions:

Voting History

• Not yet proposed.

---

Motivations

To add a schema to GeoNetwork a user currently has to:

• add the schema and ancillaries to web/geonetwork/xml/schemas directory
• add codelists and labels xml files to web/geonetwork/WEB-INF/config.xml
• add presentation xslts to web/geonetwork/xsl and import them into web/geonetwork/xsl/metadata-utils.xsl
• modify web/geonetwork/xsl/{metadata.xsl,metadata-utils.xsl} to switch on schema for full and brief mode processing
• add brief, summary and full presentation xslts to web/geonetwork/xml/csw/schemas
• add schema detection code to the autodetectSchema method in DataManager.java
• add namespaces used for elements to the tooltip javascript (web/geonetwork/scripts/editor/tooltip.js and web/geonetwork/scripts/editor/simpletooltip.js)
• schemas added to GeoNetwork exist inside the web application deployment making it more difficult to manage upgrades and new deployments of GeoNetwork

This is not only tedious but requires a fair bit of knowledge to ensure that the installation is not broken by inappropriate or incorrect changes. In some cases these changes are large enough that communities with national schemas/profiles will create their own branch of GeoNetwork to support their schema/profile. This should not be necessary.

Removing the need to make code changes and consolidating schema information will make adding a schema to GeoNetwork much easier. Having plug in schemas/profiles will also remove the need to create a code branch to support the schema/profile.

Proposal

Make the following changes:

• consolidate presentation xslts into the schema directory
• remove the need for switch on schema type in metadata.xsl and metadata-utils.xsl
• provide the ability to rewrite xslt imports using a URI resolver and oasis catalog file
• allow users to rewrite schemaLocation hints using an oasis catalog file/files
• add a SchemaManager class to encapsulate and provide schema information to other classes in GeoNetwork
• rewrite the Info service so that it no longer requires the namespace URI to be provided by the tooltip requests (will use SchemaManager to get this info instead)
• change schema autodetection code to use information from the SchemaManager (we use some code and ideas from the enhanced schema autodetect approach developed by Dominic Owen of USGIN)
• add a services that accept a zip file (or URL of a zip file) containing a schema, unpacks the schema into the schemaPlugins directory, and adds the schema to the list of schemas that GeoNetwork knows about (no config changes required)
• Move codelist and label xml file caching for schemas from Jeeves guiservices to GeoNetwork guiservices - no longer necessary to add these files to the gui section of web/geonetwork/WEB-INF/config.xml
• Add localized strings support for strings that may be used in the presentation xslts - no longer necessary to add these to the gui section of .....
• move templates and sample-data into schema directory and change gast and other code to use the SchemaManager to obtain paths to these directories

Backwards Compatibility Issues

None known?

New libraries added

xml-commons-resolver 1.2 - Apache lib to support resolving various XML entities and URIs using oasis catalogs

Risks

None known

Participants

• Simon Pigot
• Dominic Owen, USGIN - schema autodetect code
• Other members of the GeoNetwork community. In Australia: Craig Jones - IMOS/eMii, John Hockaday - OSDM, AuScope.