Hi
I see that only Z90.50 and filesystem harvesters allow to specify an xslt to apply to harvested metadata. Is there any reason to not make this option available in the other harvesters.
Thanks and regards,
Jose García
Hello Jose,
2011/11/1 jose garcia <josegar74@anonymised.com>:
Hi
I see that only Z90.50 and filesystem harvesters allow to specify an xslt to
apply to harvested metadata. Is there any reason to not make this option
available in the other harvesters.
I think some harvesters import from a fixed source format to a fixed
destination (eg. GetCapabilities doc to ISO19139) so adding a
"convert" XSLT will not be so useful because the source and
destination formats are well known (same for GeoNetwork protocols -
which could harvest records in different schema from the same node).
By the way, it could be needed to apply a transformation based on the
schema detected and not the same for all input records (like we do now
using xsl/conversion/import XSLs). But in that situation it's more a
process I think (see schema/ids/process/*.xsl). See #645 [1] which
adds a XSL filter to GeoNetwork harvester.
Cheers.
Francois
[1] http://trac.osgeo.org/geonetwork/ticket/645
Thanks and regards,
Jose García
------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
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 François,
to me it seems that all harvester types should follow the same steps, with individual implementations (which could be empty) to do the stuff necessary to each specific type of harvester.
No reason not to give an option to transform results in any way you want, by providing a “hook” to apply a transformation to the harvester result.
Seems to me that in this way, the implementation of Z3950 and Filesystem harvester result transformations, and the GeoNetwork harvester result transformation in ticket 645, should all follow a unified implementation pattern, that would be available to other harvester types as well.
E.g. list the available transformations in some folder /harvester/result-transformations; we could put some standard ones there, and site admins could create more and put them there. Sure some might not be appropriate for each type of harvester, but maybe we could ignore that, or add subfolders per harvest type in addition to general ones. The admin user who configures a harvester could then optionally add a result transformation, chosen from the available transformations in that folder.
In cases where exact transformation depends on result schema (which by the way is always the case I think), the transformation should deal with that; e.g. delegating some stuff to transformations that reside in each schema’s “process” directory.
What do you think ?
On Wed, Nov 2, 2011 at 2:48 PM, Francois Prunayre <fx.prunayre@anonymised.com> wrote:
Hello Jose,
2011/11/1 jose garcia <josegar74@anonymised.com…31…>:
Hi
I see that only Z90.50 and filesystem harvesters allow to specify an xslt to
apply to harvested metadata. Is there any reason to not make this option
available in the other harvesters.I think some harvesters import from a fixed source format to a fixed
destination (eg. GetCapabilities doc to ISO19139) so adding a
“convert” XSLT will not be so useful because the source and
destination formats are well known (same for GeoNetwork protocols -
which could harvest records in different schema from the same node).By the way, it could be needed to apply a transformation based on the
schema detected and not the same for all input records (like we do now
using xsl/conversion/import XSLs). But in that situation it’s more a
process I think (see schema/ids/process/*.xsl). See #645 [1] which
adds a XSL filter to GeoNetwork harvester.Cheers.
Francois
[1] http://trac.osgeo.org/geonetwork/ticket/645
Thanks and regards,
Jose García
RSA® Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
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
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
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 Heikki,
2011/11/2 heikki <tropicano@anonymised.com>:
hi François,
to me it seems that all harvester types should follow the same steps, with
individual implementations (which could be empty) to do the stuff necessary
to each specific type of harvester.No reason not to give an option to transform results in any way you want, by
providing a "hook" to apply a transformation to the harvester result.
Seems to me that in this way, the implementation of Z3950 and Filesystem
harvester result transformations, and the GeoNetwork harvester result
transformation in ticket 645, should all follow a unified implementation
pattern,
I agree.
that would be available to other harvester types as well.
E.g. list the available transformations in some folder
/harvester/result-transformations; we could put some standard ones there,
and site admins could create more and put them there. Sure some might not be
appropriate for each type of harvester, but maybe we could ignore that, or
add subfolders per harvest type in addition to general ones. The admin user
who configures a harvester could then optionally add a result
transformation, chosen from the available transformations in that folder.
In cases where exact transformation depends on result schema (which by the
way is always the case I think),
I think so too.
Francois
the transformation should deal with that;
e.g. delegating some stuff to transformations that reside in each schema's
"process" directory.What do you think ?
On Wed, Nov 2, 2011 at 2:48 PM, Francois Prunayre <fx.prunayre@anonymised.com>
wrote:Hello Jose,
2011/11/1 jose garcia <josegar74@anonymised.com>:
> Hi
> I see that only Z90.50 and filesystem harvesters allow to specify an
> xslt to
> apply to harvested metadata. Is there any reason to not make this option
> available in the other harvesters.
I think some harvesters import from a fixed source format to a fixed
destination (eg. GetCapabilities doc to ISO19139) so adding a
"convert" XSLT will not be so useful because the source and
destination formats are well known (same for GeoNetwork protocols -
which could harvest records in different schema from the same node).By the way, it could be needed to apply a transformation based on the
schema detected and not the same for all input records (like we do now
using xsl/conversion/import XSLs). But in that situation it's more a
process I think (see schema/ids/process/*.xsl). See #645 [1] which
adds a XSL filter to GeoNetwork harvester.Cheers.
Francois
[1] http://trac.osgeo.org/geonetwork/ticket/645
> Thanks and regards,
> Jose García
>
> ------------------------------------------------------------------------------
> RSA® Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> 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
>------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
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