[GeoNetwork-devel] Considerations about schema-conversion

GeoNetwork GeoNetwork Developer
1

Hi list,

working on a iso19139 profile (on branch 2.10.x), I came across the schema-
conversion stuff.

Let's see the xml definition of a converter:
  <converter name="xml_csw-record"
               nsUri="http://www.isotc211.org/2005/gmd&quot;
               schemaLocation="www.isotc211.org/2005/gmd/gmd.xsd"
               xslt="etcetera"/>

The documentation in the file says that the "name" defines the geonetwork
service name, and the "xslt" is the name of the xsl stylesheet to call for
converting the metadata.
The "name" attribute is also used to select the label for the button that will
export the metadata using the given converter.

The first consideration is that, for creating a proper converter, the comments
are suggesting the implementors to create a set of new services.
Now, if I am defining a schema plugin to be used with a stock GeoNetwork, I may
not want to create a brand new service.
I may externalize the service definition using the overriding mechanism, but a
schema plugin should work only by adding the currently documented stuff;
the override is not automatic, so the override file should be provided
somewhere outside of the plugin, and geonetwork should be externally configured
to read from this override file.
This is to say that we may want to use some predefined services to serve as
many converters as possible. This leads to the second condideration.

Second consideration:
Let's say that generically we may use a single Convert service and a proper
xsl file. It means that I may want to use the same service applied to different
xsl files, in order to have different transformation. This is not possibile at
the moment, since the localization logic (in xsl files) uses the service name
as a key for the localization.

A minor change in the XSL makes it possible to use a new attribute, "service",
to define the service name, and use "name" for the localization.

e.g.:
  <converter name="myprofile2iso19139"
               service="basicconverter"
               xslt="myprofile2iso19139.xsl"/>

  <converter name="myprofile2dc"
               service="basicconverter"
               xslt="myprofile2dc.xsl"/>

The labels would be bound to the name, so the same service could be used more
than once. The change would be back compatible, setting 'service' with the
value of 'name' if not defined.

Another consideration/question:
are the nsUri and schemaLocation attributes ever used?
nsUri is used in SchemaManager.existsConverter(), but I could not find any
place where this method is called.

   Ciao,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

2

Hi Emanuele,

I think the minor change to add the service attribute to the schema conversions file that you describe below is a good idea! Are you going to implement it?

The nsUri attribute is used in the SchemaManager existsConverter method as a way of locating a particular converter (this could be exposed through a service so a particular GeoNetwork instance could be asked whether schemas/profiles support such a conversion to a particular namespace). The schemaLocation attribute isn't used at present (from memory) but the intention was that it be used with the nsUri to help locate/narrow down options when looking for a particular converter as compatible metadata schemas/profiles may have the same namespace URI but different schema locations each of which might be served by a different converter. However to my knowledge the schemaLocation attribute isn't used in this way yet.

Cheers,
Simon
________________________________________
From: Emanuele Tajariol [etj@anonymised.com]
Sent: Friday, 8 November 2013 4:10 AM
To: GeoNetwork Developer list
Subject: [GeoNetwork-devel] Considerations about schema-conversion

Hi list,

working on a iso19139 profile (on branch 2.10.x), I came across the schema-
conversion stuff.

Let's see the xml definition of a converter:
        <converter name="xml_csw-record"
               nsUri="http://www.isotc211.org/2005/gmd&quot;
               schemaLocation="www.isotc211.org/2005/gmd/gmd.xsd"
               xslt="etcetera"/>

The documentation in the file says that the "name" defines the geonetwork
service name, and the "xslt" is the name of the xsl stylesheet to call for
converting the metadata.
The "name" attribute is also used to select the label for the button that will
export the metadata using the given converter.

The first consideration is that, for creating a proper converter, the comments
are suggesting the implementors to create a set of new services.
Now, if I am defining a schema plugin to be used with a stock GeoNetwork, I may
not want to create a brand new service.
I may externalize the service definition using the overriding mechanism, but a
schema plugin should work only by adding the currently documented stuff;
the override is not automatic, so the override file should be provided
somewhere outside of the plugin, and geonetwork should be externally configured
to read from this override file.
This is to say that we may want to use some predefined services to serve as
many converters as possible. This leads to the second condideration.

Second consideration:
Let's say that generically we may use a single Convert service and a proper
xsl file. It means that I may want to use the same service applied to different
xsl files, in order to have different transformation. This is not possibile at
the moment, since the localization logic (in xsl files) uses the service name
as a key for the localization.

A minor change in the XSL makes it possible to use a new attribute, "service",
to define the service name, and use "name" for the localization.

e.g.:
        <converter name="myprofile2iso19139"
               service="basicconverter"
               xslt="myprofile2iso19139.xsl"/>

        <converter name="myprofile2dc"
               service="basicconverter"
               xslt="myprofile2dc.xsl"/>

The labels would be bound to the name, so the same service could be used more
than once. The change would be back compatible, setting 'service' with the
value of 'name' if not defined.

Another consideration/question:
are the nsUri and schemaLocation attributes ever used?
nsUri is used in SchemaManager.existsConverter(), but I could not find any
place where this method is called.

   Ciao,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://twitter.com/geosolutions_it

-------------------------------------------------------

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net

GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

3

Hi Simon,

Alle 05:12:30 di Friday 8 November 2013, Simon.Pigot@anonymised.com ha scritto:

Hi Emanuele,

I think the minor change to add the service attribute to the schema
conversions file that you describe below is a good idea! Are you going to
implement it?

Sure, please take a look at this pull request
   https://github.com/geonetwork/core-geonetwork/pull/296

(both commits are needed)

   Ciao,
   Emanuele

The nsUri attribute is used in the SchemaManager existsConverter method as
a way of locating a particular converter (this could be exposed through a
service so a particular GeoNetwork instance could be asked whether
schemas/profiles support such a conversion to a particular namespace). The
schemaLocation attribute isn't used at present (from memory) but the
intention was that it be used with the nsUri to help locate/narrow down
options when looking for a particular converter as compatible metadata
schemas/profiles may have the same namespace URI but different schema
locations each of which might be served by a different converter. However
to my knowledge the schemaLocation attribute isn't used in this way yet.

Cheers,
Simon
________________________________________
From: Emanuele Tajariol [etj@anonymised.com]
Sent: Friday, 8 November 2013 4:10 AM
To: GeoNetwork Developer list
Subject: [GeoNetwork-devel] Considerations about schema-conversion

Hi list,

working on a iso19139 profile (on branch 2.10.x), I came across the schema-
conversion stuff.

Let's see the xml definition of a converter:
        <converter name="xml_csw-record"
               nsUri="http://www.isotc211.org/2005/gmd&quot;
               schemaLocation="www.isotc211.org/2005/gmd/gmd.xsd"
               xslt="etcetera"/>

The documentation in the file says that the "name" defines the geonetwork
service name, and the "xslt" is the name of the xsl stylesheet to call for
converting the metadata.
The "name" attribute is also used to select the label for the button that
will export the metadata using the given converter.

The first consideration is that, for creating a proper converter, the
comments are suggesting the implementors to create a set of new services.
Now, if I am defining a schema plugin to be used with a stock GeoNetwork, I
may not want to create a brand new service.
I may externalize the service definition using the overriding mechanism,
but a schema plugin should work only by adding the currently documented
stuff; the override is not automatic, so the override file should be
provided somewhere outside of the plugin, and geonetwork should be
externally configured to read from this override file.
This is to say that we may want to use some predefined services to serve as
many converters as possible. This leads to the second condideration.

Second consideration:
Let's say that generically we may use a single Convert service and a proper
xsl file. It means that I may want to use the same service applied to
different xsl files, in order to have different transformation. This is
not possibile at the moment, since the localization logic (in xsl files)
uses the service name as a key for the localization.

A minor change in the XSL makes it possible to use a new attribute,
"service", to define the service name, and use "name" for the
localization.

e.g.:
        <converter name="myprofile2iso19139"
               service="basicconverter"
               xslt="myprofile2iso19139.xsl"/>

        <converter name="myprofile2dc"
               service="basicconverter"
               xslt="myprofile2dc.xsl"/>

The labels would be bound to the name, so the same service could be used
more than once. The change would be back compatible, setting 'service'
with the value of 'name' if not defined.

Another consideration/question:
are the nsUri and schemaLocation attributes ever used?
nsUri is used in SchemaManager.existsConverter(), but I could not find any
place where this method is called.

   Ciao,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

4

Hi Simon and list,

thinking a bit about the nsURI in schema conversion:
couldn't this be used to convert metadata for CSW requests, according to the
CSW outputSchema parameter?
The crossrelation with ESN should be somehow solved anyway.

   Ciao,
   Emanuele

Alle 05:12:30 di Friday 8 November 2013, Simon.Pigot@anonymised.com ha scritto:

Hi Emanuele,

I think the minor change to add the service attribute to the schema
conversions file that you describe below is a good idea! Are you going to
implement it?

The nsUri attribute is used in the SchemaManager existsConverter method as
a way of locating a particular converter (this could be exposed through a
service so a particular GeoNetwork instance could be asked whether
schemas/profiles support such a conversion to a particular namespace). The
schemaLocation attribute isn't used at present (from memory) but the
intention was that it be used with the nsUri to help locate/narrow down
options when looking for a particular converter as compatible metadata
schemas/profiles may have the same namespace URI but different schema
locations each of which might be served by a different converter. However
to my knowledge the schemaLocation attribute isn't used in this way yet.

Cheers,
Simon
________________________________________
From: Emanuele Tajariol [etj@anonymised.com]
Sent: Friday, 8 November 2013 4:10 AM
To: GeoNetwork Developer list
Subject: [GeoNetwork-devel] Considerations about schema-conversion

Hi list,

working on a iso19139 profile (on branch 2.10.x), I came across the schema-
conversion stuff.

Let's see the xml definition of a converter:
        <converter name="xml_csw-record"
               nsUri="http://www.isotc211.org/2005/gmd&quot;
               schemaLocation="www.isotc211.org/2005/gmd/gmd.xsd"
               xslt="etcetera"/>

The documentation in the file says that the "name" defines the geonetwork
service name, and the "xslt" is the name of the xsl stylesheet to call for
converting the metadata.
The "name" attribute is also used to select the label for the button that
will export the metadata using the given converter.

The first consideration is that, for creating a proper converter, the
comments are suggesting the implementors to create a set of new services.
Now, if I am defining a schema plugin to be used with a stock GeoNetwork, I
may not want to create a brand new service.
I may externalize the service definition using the overriding mechanism,
but a schema plugin should work only by adding the currently documented
stuff; the override is not automatic, so the override file should be
provided somewhere outside of the plugin, and geonetwork should be
externally configured to read from this override file.
This is to say that we may want to use some predefined services to serve as
many converters as possible. This leads to the second condideration.

Second consideration:
Let's say that generically we may use a single Convert service and a proper
xsl file. It means that I may want to use the same service applied to
different xsl files, in order to have different transformation. This is
not possibile at the moment, since the localization logic (in xsl files)
uses the service name as a key for the localization.

A minor change in the XSL makes it possible to use a new attribute,
"service", to define the service name, and use "name" for the
localization.

e.g.:
        <converter name="myprofile2iso19139"
               service="basicconverter"
               xslt="myprofile2iso19139.xsl"/>

        <converter name="myprofile2dc"
               service="basicconverter"
               xslt="myprofile2dc.xsl"/>

The labels would be bound to the name, so the same service could be used
more than once. The change would be back compatible, setting 'service'
with the value of 'name' if not defined.

Another consideration/question:
are the nsUri and schemaLocation attributes ever used?
nsUri is used in SchemaManager.existsConverter(), but I could not find any
place where this method is called.

   Ciao,
   Emanuele

--

Our support, Your Success!
Visit http://opensdi.geo-solutions.it for more information.

Ing. Emanuele Tajariol
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 380 2116282

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------