Sparse to the point of being unhelpful I'd say 
The untidy state of this dir has been bugging me for a while. The purpose of the convert directory is to provide schema specific XSLTs to convert metadata to/from that schema (so the spare statement is right). However the layout of the dir and its contents needs further discussion and maybe this is a good opportunity for rationalization to make things clearer:
- Some XSLTs eg. xml_iso19139.xsl are used to provide on the fly conversions in the search results and metadata show windows - see WEB-INF/config-export.xml eg. the service xml_iso19139 calls xml_iso19139.xsl (this is probably the source for the sparse comment above)
- oai_dc.xsl is used to convert schema records to oai_dc format on the fly for the OAIPMH harvester (and configured in WEB-INF/config-oai-prefixes.xml - can be other converters for this as well - there is an example in there)
- the functions.xsl file is used by index-fields.xsl and update-fixed-info.xsl - it should move up into the same directory as the xslts that use it or possibly into an xslt-includes subdirectory of the schema so it doesn't cause confusion here
- the convert directory also contains optional subdirectories used by harvesters for specific transformations to/from the schema if supported - in particular:
ThreddsDIFToISO - XSLTs for converting Thredds catalog metadata in DIF format to the schema - thredds harvester
ThreddsToFragments - XSLTs for converting Thredds catalog metadata to schema (fragments) - thredds harvester
WFSToFragments - XSLTs for converting WFS GetFeature requests to schema (fragments) - wfs harvester
OGCWxSGetCapabilitiesto19119 - XSLTs for converting GetCaps responses to 19119 service descriptions for this schema - OGCWxS harvester
So after all that - my feeling is that rather than rely just on a naming convention, each schema should have a config that describes the conversions it supports (to be read by the SchemaManager) eg:
<schema name="iso19139" nsUrl="http://www.isotc211.org/2005/gmd" schemaLocation="http://www.isotc211.org/2005/gmd/gmd\.xsd" xslt="xml_iso19139.xsl"/> <!-- localized description of what xml_iso19139.xsl does in schema strings file? -->
This could then be used for your use-case but also for others as it contains not just the name of the converter but the namespace produced (which could also be used to search for a matching converter).
Maybe there is a better alternative? In any case I'd like to get this (or something like it) in place asap as this needs to be in a state where it can be properly documented and used.
Cheers,
Simon
________________________________________
From: heikki [tropicano@anonymised.com]
Sent: Tuesday, 14 February 2012 10:55 PM
To: Devel geonetwork-devel@lists.sourceforge.net
Subject: [GeoNetwork-devel] Plugin profiles conversion question
hello,
I have a plugin profile that uses its own schema, overriding some of the standard ISO19139 elements.
My goal is that the CSW server by default returns the metadata as they are (using the profile schema) but when clients ask for , it should apply an XSLT to convert the overridden elements back to their standard ISO ones.
The documentation says this :
"If the new GeoNetwork plugin schema is to support on the fly translation of metadata records to other schemas, then the convert directory should be created and populated with appropriate XSLTs." (see http://geonetwork-opensource.org/manuals/trunk/eng/developer/schemaPlugins/index.html).
But I find this explanation a bit sparse. For example, how should these XSLTs be named, in order to be applied when client asks for some particular outputschema ?
I tried creating an XSLT called "to19139.xsl" in the /convert directory, analogous to how it is in the French profile. However when clients ask for outputschema GMD — Resource site for ISO/TC 211 Geographic information/Geomatics, it seems this XSLT is not applied and the md are returned as is (with the profile schema elements).
What should I do to make that work ?
Kind regards
Heikki Doeleman
