| 48 | | || 17 || || Feedback / Enhancement ||GeoNetwork needs a range of metadata editors and the ANZMet Lite (a wizard based editor available for download from [http://anzlicmet.bluenet.utas.edu.au here]) should be part of the toolkit. ANZMet Lite needs to be open sourced under (GPL) to be distributed with GeoNetwork. Comments: If the web interface were improved, the need for ANZMet Lite would be reduced. There is a need for “offline” metadata creation when researchers or data collectors are not connected to the Internet – this is where ANZMet Lite has unique value. Why not improve the existing GeoNetwork editor (see geocat.ch editor, merge some of the features into the trunk)? Justification/Action: Add ANZMet Lite as a user friendly, Wizard based PC editing interface with the flexibility to meet the needs of different users. Simon Pigot has already added GeoNetwork upload/download to ANZMet Lite. || heikki: 4 || Documentation for option to add an editor || |
| 49 | | || 18 || ||API enhancements || GeoNetwork services and JavaScript API need to be documented so that the user interface can be replaced and/or the existing functionality reused or customized. A different user interface skin should be easy to apply. The new Jeeves test framework offers an opportunity to document the inputs and outputs of the services. Action/Justification: The existing JavaScript API (web/geonetwork/scripts/core) needs to be documented and extended – existing code that doesn’t use the API needs to be refactored. Note: !GeoNetwork xml services documentation exists in manual. || heikki: 2 || |
| 50 | | || 19 || || Code cleaning (client part)||The technologies that are used in the user interface are not homogenous: XSLT, HTML and !JavaScript are often mixed and hard to separate - this makes development and modification of the user interface difficult - but given the current architecture of !GeoNetwork, a complete separation into components based on implementation language is impossible. Action: Separate the HTML, XML and JavaScript from each other so that a skilled interface designer does not need to know all three technologies to change the interface. || heikki: 4 | jose: major || |
| 51 | | || 20 || || XML fragment||Reusing fragments of metadata (XML) – “object reuse”. Fragments are implemented in various sandboxes. Metadata records can be composed from fragments using XLinks and there is an XLinks URL Resolver. Community action needs to be consolidated through the fragments proposal. Many organisations would like GeoNetwork to be able to harvest fragments from relational databases as they often generate full metadata records from relational databases using custom software. If the database information changes, these records then need to be re-harvested. Some organisations would also like to be able to edit the fragments in !GeoNetwork and return them to the database from which they were harvested. Action/Justification: Integrating fragments of metadata that are managed in an external system (i.e. relational database, authentication directory). There is a mechanism for implementation for metadata fragment harvesting from relational databases via a WFS in the BlueNetMEST sandbox. This work needs to be consolidated with work in the geocat.ch and geosource sandboxes and added to the trunk. This work should also be extended to allow metadata fragments in the relational database to be updated after editing in !GeoNetwork. Harvesting of fragments from authentication directories (eg. LDAP) should be added. ||Partially done by Simon ? || || |
| 52 | | || 21 || || Metadata versioning || !GeoNetwork needs some form of version control to track changes made to a metadata record over time. Action/Justification: This can be done inside the database without needing to externalise the metadata records. That way you can index and search on the old versions as well, if desired. Alternatively it could be done externally using perhaps a Java interface to subversion or through an interface to existing enterprise document management systems or perhaps using a different database approach for the documents eg. CouchDB. See also [http://geoserver.org/display/GEOS/Versioning+WFS this] approach to versioning WFS content?|| heikki: 3 || Nice to have |
| 53 | | || 22 || || Community || Some aspects of project planning for !GeoNetwork are not visible to those outside the project steering committee. Action: Continue to adopt and implement OSGeo best practise (e.g. GeoServer).|| heikki: 2 || Developper mailing list, IRC, trac || |
| 54 | | || 23 || ||Documentation / Community ||Documentation for ‘Implementing !GeoNetwork into your organisation’ should be provided. Rather than changing the perspective of the current documentation from "how to" from "it does", perhaps you can have different documentation for different audiences. The “how to” section of the Trac is very useful. Action: As the “how to” section of the OSGeo !GeoNetwork trac site expands, it could be linked into the documentation. || heikki: 2 || Migration to sphinx on its way || |
| 55 | | || 24 || ||Index enhancement ||!GeoNetwork’s current Lucene field / index names and the mapping of metadata fields to these Lucene field names are ad hoc. This has the potential to prevent search interoperability between catalogues. Action: !GeoNetwork should use an established mapping such as the geo profile of Z3950 (including attributes, data and relations) to define Lucene field names and the mapping from metadata elements to Lucene fields for all metadata schemas. || heikki: 2 || Create mapping table in the documentation || |
| 56 | | || 25 || ||Validation enhancement||XSD and Schematron Validators return errors that are meaningless to most users. Ability to customise the error messages easily would be useful. Action: Code containing XSD validation messages needs to be modified to include alternative or additional messages to those already in use. Schematron diagnostics specified in rules should be made more useful to users. setErrorHandler already in use - could me modded to support more meaningful messages? Francois has updated schematron to schematron validation and reporting language.|| heikki: 1 || Improve XSD error reporting (localized message ?) || |
| | 48 | || 17 || || Feedback / Enhancement ||GeoNetwork needs a range of metadata editors and the ANZMet Lite (a wizard based editor available for download from [http://anzlicmet.bluenet.utas.edu.au here]) should be part of the toolkit. ANZMet Lite needs to be open sourced under (GPL) to be distributed with GeoNetwork. Comments: If the web interface were improved, the need for ANZMet Lite would be reduced. There is a need for “offline” metadata creation when researchers or data collectors are not connected to the Internet – this is where ANZMet Lite has unique value. Why not improve the existing GeoNetwork editor (see geocat.ch editor, merge some of the features into the trunk)? Justification/Action: Add ANZMet Lite as a user friendly, Wizard based PC editing interface with the flexibility to meet the needs of different users. Simon Pigot has already added GeoNetwork upload/download to ANZMet Lite. || heikki: 4 || Documentation about how an editor can interface with GeoNetwork needs to be written. This could be as simple as noting which services in the xml services manual can be used by an external editor. || |
| | 49 | || 18 || ||API enhancements || GeoNetwork services and JavaScript API need to be documented so that the user interface can be replaced and/or the existing functionality reused or customized. A different user interface skin should be easy to apply. The new Jeeves test framework offers an opportunity to document the inputs and outputs of the services. Action/Justification: The existing JavaScript API (web/geonetwork/scripts/core) needs to be documented and extended – existing code that doesn’t use the API needs to be refactored. Note: !GeoNetwork xml services documentation exists in manual. || heikki: 2 || Guiwidgets sandbox provides a Javascript only user interface that can be installed as a separate module. It uses the ext-js javascript library which is well documented already and openlayers for map windows. || |
| | 50 | || 19 || || Code cleaning (client part)||The technologies that are used in the user interface are not homogenous: XSLT, HTML and !JavaScript are often mixed and hard to separate - this makes development and modification of the user interface difficult - but given the current architecture of !GeoNetwork, a complete separation into components based on implementation language is impossible. Action: Separate the HTML, XML and JavaScript from each other so that a skilled interface designer does not need to know all three technologies to change the interface. || heikki: 4 | jose: major || Guiwidgets sandbox provides a Javascript only user interface that can be installed as a separate module. When this is integrated most if not all of the XSLT that produces HTML can be deprecated. || |
| | 51 | || 20 || || XML fragment||Reusing fragments of metadata (XML) – “object reuse”. Fragments are implemented in various sandboxes. Metadata records can be composed from fragments using XLinks and there is an XLinks URL Resolver. Community action needs to be consolidated through the fragments proposal. Many organisations would like GeoNetwork to be able to harvest fragments from relational databases as they often generate full metadata records from relational databases using custom software. If the database information changes, these records then need to be re-harvested. Some organisations would also like to be able to edit the fragments in !GeoNetwork and return them to the database from which they were harvested. Action/Justification: Integrating fragments of metadata that are managed in an external system (i.e. relational database, authentication directory). There is a mechanism for implementation for metadata fragment harvesting from relational databases via a WFS in the BlueNetMEST sandbox. This work needs to be consolidated with work in the geocat.ch and geosource sandboxes and added to the trunk. This work should also be extended to allow metadata fragments in the relational database to be updated after editing in !GeoNetwork. Harvesting of fragments from authentication directories (eg. LDAP) should be added. || All implemented except for harvesting from authentication directories. || || |
| | 52 | || 21 || || Metadata versioning || !GeoNetwork needs some form of version control to track changes made to a metadata record over time. Action/Justification: This can be done inside the database without needing to externalise the metadata records. That way you can index and search on the old versions as well, if desired. Alternatively it could be done externally using perhaps a Java interface to subversion or through an interface to existing enterprise document management systems or perhaps using a different database approach for the documents eg. CouchDB. See also [http://geoserver.org/display/GEOS/Versioning+WFS this] approach to versioning WFS content?|| heikki: 3 || Nice to have - maybe a collaboration between WMO and some Australian groups will produce this as WMO are also interested. || |
| | 53 | || 22 || || Community || Some aspects of project planning for !GeoNetwork are not visible to those outside the project steering committee. Action: Continue to adopt and implement OSGeo best practise (e.g. GeoServer).|| heikki: 2 || Developer mailing list, IRC, trac and especially proposals are beginning to show more of this detail. || |
| | 54 | || 23 || ||Documentation / Community ||Documentation for ‘Implementing !GeoNetwork into your organisation’ should be provided. Rather than changing the perspective of the current documentation from "how to" from "it does", perhaps you can have different documentation for different audiences. The “how to” section of the Trac is very useful. Action: As the “how to” section of the OSGeo !GeoNetwork trac site expands, it could be linked into the documentation. || heikki: 2 || Migration to sphinx is taking place - this will not only provide a more attractive presentation of the documentation, it will also allow text from these pages to be more easily included/linked. || |
| | 55 | || 24 || ||Index enhancement ||!GeoNetwork’s current Lucene field / index names and the mapping of metadata fields to these Lucene field names are ad hoc. This has the potential to prevent search interoperability between catalogues. Action: !GeoNetwork should use an established mapping such as the geo profile of Z3950 (including attributes, data and relations) to define Lucene field names and the mapping from metadata elements to Lucene fields for all metadata schemas. || heikki: 2 || One interim option is to create a mapping table in the documentation but it is agreed that the names should be standardized. || |
| | 56 | || 25 || ||Validation enhancement||XSD and Schematron Validators return errors that are meaningless to most users. Ability to customise the error messages easily would be useful. Action: Code containing XSD validation messages needs to be modified to include alternative or additional messages to those already in use. Schematron diagnostics specified in rules should be made more useful to users. setErrorHandler already in use - could me modded to support more meaningful messages? Francois has updated schematron to schematron validation and reporting language.|| heikki: 1 || Improve XSD error reporting - functions to do this have been committed to 2.7 - see || |
