| 34 | | ||12 || ||Code Refactoring || The class {{{DataManager.java}}} and its sister {{{XMLSerializer.java}}} are in particularly bad shape, in my opinion. There are literally dozens of public methods that all do more or less the same thing. Of course it's not clearly documented why they are all there or when to use which. Would it be too drastic to propose that we keep 1 single public method for each of the functions ''createMetadata'', ''updateMetadata'', ''validateMetadata'', etc. ? || |
| 35 | | ||13|| || RIA, Framework || Any relevant software going on that might be useful for GeoNetwork? Think of [http://mapproxy.org/ MapProxy], [http://chiba.sourceforge.net Chiba] and [http://geojquery.org/wiki/doku.php GeoJQuery]. Other ones? || |
| 36 | | ||14|| ||Editor enhancement || In the [http://nationaalgeoregister.nl NGR] project, a modification to the code around the editor called ''Inflation and Vacuum'' is implemented, that makes it much easier to create valid metadata from scratch. In essence it takes the function of {{{update-fixed-info.xsl}}} (which also tries to do some automatic adjustments to help things along) a whole seven miles further. What do the developers think of this? (I'll provide documentation sometime soon). || |
| 37 | | ||15|| ||Framework / Refactoring ||Whether it's going to happen soon or not, I still think it good to repeat the subject of what to choose if we ever get to a drastic make-over of current GeoNetwork code, especially in terms of (1) GUI: use [http://wicket.apache.org/ Wicket]? [http://code.google.com/webtoolkit/ GWT]? (2) MVC: use [http://struts.apache.org/2.x/ Struts]? [http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html Spring MVC]? (3) Persistence: use [http://www.hibernate.org/ Hibernate]? use [http://java.sun.com/developer/technicalArticles/J2EE/jpa/ JPA/EJB3]? (4) Web Services: use [http://ws.apache.org/axis2/ Axis2]? [http://jcp.org/en/jsr/summary?id=311 Jax-RS]? || |
| 38 | | || 16 || ||Editor enhancement (XForms) ||GeoNetwork needs a range of metadata editors and the XForms Editor (from geonetworkui sandbox) should be available as part of this range. An XForms engine is an alternative technology that potentially hides details of HTML and JavaScript from developers. (The usefulness of the XForms editor will be determined to a large extent by how well it works across browsers and how responsive it is. What does the "potentially hides details" bit actually mean? That's just wishful thinking, and adding XForms means yet another complicated technology for developers to master. Justification/Action: Develop XForms interface as providing a user friendly interface with the flexibility to meet the needs of different users. How does it relate to [http://chiba.sourceforge.net Chiba]? || |
| 39 | | || 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. || |
| 40 | | || 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. || |
| 41 | | || 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. || |
| | 34 | ||12 || ||Code Refactoring || The class {{{DataManager.java}}} and its sister {{{XMLSerializer.java}}} are in particularly bad shape, in my opinion. There are literally dozens of public methods that all do more or less the same thing. Of course it's not clearly documented why they are all there or when to use which. Would it be too drastic to propose that we keep 1 single public method for each of the functions ''createMetadata'', ''updateMetadata'', ''validateMetadata'', etc. ? || heikki: 1 || |
| | 35 | ||13|| || RIA, Framework || Any relevant software going on that might be useful for GeoNetwork? Think of [http://mapproxy.org/ MapProxy], [http://chiba.sourceforge.net Chiba] and [http://geojquery.org/wiki/doku.php GeoJQuery]. Other ones? || heikki: 4 || |
| | 36 | ||14|| ||Editor enhancement || In the [http://nationaalgeoregister.nl NGR] project, a modification to the code around the editor called ''Inflation and Vacuum'' is implemented, that makes it much easier to create valid metadata from scratch. In essence it takes the function of {{{update-fixed-info.xsl}}} (which also tries to do some automatic adjustments to help things along) a whole seven miles further. What do the developers think of this? (I'll provide documentation sometime soon). || heikki: 3 || |
| | 37 | ||15|| ||Framework / Refactoring ||Whether it's going to happen soon or not, I still think it good to repeat the subject of what to choose if we ever get to a drastic make-over of current GeoNetwork code, especially in terms of (1) GUI: use [http://wicket.apache.org/ Wicket]? [http://code.google.com/webtoolkit/ GWT]? (2) MVC: use [http://struts.apache.org/2.x/ Struts]? [http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html Spring MVC]? (3) Persistence: use [http://www.hibernate.org/ Hibernate]? use [http://java.sun.com/developer/technicalArticles/J2EE/jpa/ JPA/EJB3]? (4) Web Services: use [http://ws.apache.org/axis2/ Axis2]? [http://jcp.org/en/jsr/summary?id=311 Jax-RS]? || heikki: 3 || |
| | 38 | || 16 || ||Editor enhancement (XForms) ||GeoNetwork needs a range of metadata editors and the XForms Editor (from geonetworkui sandbox) should be available as part of this range. An XForms engine is an alternative technology that potentially hides details of HTML and JavaScript from developers. (The usefulness of the XForms editor will be determined to a large extent by how well it works across browsers and how responsive it is. What does the "potentially hides details" bit actually mean? That's just wishful thinking, and adding XForms means yet another complicated technology for developers to master. Justification/Action: Develop XForms interface as providing a user friendly interface with the flexibility to meet the needs of different users. How does it relate to [http://chiba.sourceforge.net Chiba]? || heikki: 3 || |
| | 39 | || 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 || |
| | 40 | || 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 || |
| | 41 | || 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 || |
| 43 | | || 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?|| |
| 44 | | || 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).|| |
| 45 | | || 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. || |
| 46 | | || 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. || |
| 47 | | || 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.|| |
| 48 | | || 26 || ||Documentation ||!GeoNetwork requires a generic capability for element help, code list choices and suggestions to be linked to metadata guidelines provided with profiles/standards. Action: !GeoNetwork to call documentation components from external sources (e.g. mouse over tool tips from profile/standard and code list documentation). || |
| 49 | | || 27 || || Metadata categories||!GeoNetwork categories are not related to metadata content – should be configurable from content. Action: !GeoNetwork should be able to configure dynamic categories from a Lucene field. Eg. An administrator could create category names as unique values of the Lucene field name purpose (which might be mapped to gmd:purpose for ISO) – records would belong to the category described by purpose cf. also discussion on dynamic categories ie. categories that are placeholders for a saved search. || |
| 50 | | || 28 || ||Tag cloud || GeoNetwork currently does not manage its own tag cloud / Folksonomy. Action: !GeoNetwork could optionally manage these things internally rather than using a third party social networking site. [http://trac.osgeo.org/geonetwork/ticket/96 Ticket 96 suggests a way of doing this]|| |
| 51 | | || 29 || ||Harvester / Network-crawling ||Network-crawling for geo-resources. Action: GeoNetwork needs to continue to be aware of and exploit initiatives for automatic harvesting of metadata from geo-resources. Eg. Metadata extraction tools such as the Talend Spatial Data Integrator suite etc || |
| 52 | | || 30 || ||Metadata identifier ||!GeoNetwork lacks the ability to consistently reproduce a unique identifier for the same geo resource (e.g. same dataset stored in two different locations) and/or use persistent identifier services. This is somewhere along the range from "easy enough" to "very difficult", need to spell out the precise details of the set of features you have in mind. Action: GeoNetwork needs to be able to generate, store and use metadata identifiers (eg, gmd:fileIdentifier) as well as data identifiers using the current stand alone UUID, but also (for data objects) MD5 (including what the checksum was generated from) and identifiers from external persistent identifier services (It should be possible to obtain persistent identifiers for both metadata and data from external persistent identifier services). || |
| 53 | | || 31 || ||Interoperability / resources discovery||Better inter-application interoperability. GeoNetwork needs to rethink the interoperability with the emerging FOSS such as the way that OpenLayers is designing / redeveloping its interface. e.g. use of GeoExt; e.g. GeoNetwork needs to provide simple mechanisms to allow discovered resources to be exploited and utilised in complementary open source software; e.g. drag-and-drop discovered resources into OpenLayers or GeoServer. Action: Better intra-application interoperability. GeoNetwork needs to coordinate the discovery of resources with the publication of those same resources in FOSS such as GeoServer. || |
| 54 | | || 32 || ||Data management ||!GeoNetwork assumes resources that are tagged as data for download in gmd:protocol are local. Action: GeoNetwork needs to allow for the fact that data tagged as data for download may not be local. || |
| 55 | | || 33 || ||Remote search||Remote search across a number of sites returns a pre-selected number of hits from all remote sites (pre-selected number is a search option) – it should return these hits from each site. Action: Presentation of pre-selected number of hits from each remote site – may require more delving into JZKit. || |
| 56 | | || 34 || ||Remote search||Presentation of returned hits from remote sites may be very slow because search is limited by the speed of the slowest site. Action: Presentations of first returned hits from first responding remote site should not have to wait on the slowest site – may require more delving into JZKit. || |
| 57 | | || 35 || ||Configuration||There are too many configuration files in too many places eg. repositories.xml.tem and not all configuration options are supported by the existing admin interfaces. Action: Continue to consolidate configuration options in the system configuration interface. || |
| 58 | | || 36 || ||Web map client|| There is no documentation for the implementation of alternative web map clients to Intermap and this makes it appear that the process is far harder than it actually is. Given the enthusiasm for an OpenLayers-based interface, what "interface" there currently is will probably soon be rapidly-evolving - if not replaced completely. Action: Document the interface that GeoNetwork uses to call a web map client so that sites can substitute their own.|| |
| 59 | | || 37 || ||Distributed search||Current capability of !GeoNetwork to use distributed searching is given a low priority and not being developed when compared with the local search. Action: More consideration is required towards distributed searches and proper attention should be given to it.|| |
| 60 | | || 38 || ||Distributed CSW search|| Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented. || |
| 61 | | || 39 || || XML validation|| Potential for remotely accessed information to be malicious. Action: !GeoNetwork should validate all XML inputs and responses (eg. as it does for CSW) and check expected MIME types e.g. you ask for a GIF, you get a GIF. And indicate / reject non-conforming content with a warning?|| |
| | 43 | || 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 || |
| | 44 | || 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 || |
| | 45 | || 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 || |
| | 46 | || 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 || |
| | 47 | || 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 || |
| | 48 | || 26 || ||Documentation ||!GeoNetwork requires a generic capability for element help, code list choices and suggestions to be linked to metadata guidelines provided with profiles/standards. Action: !GeoNetwork to call documentation components from external sources (e.g. mouse over tool tips from profile/standard and code list documentation). || Partially done in NGR by Jose || |
| | 49 | || 27 || || Metadata categories||!GeoNetwork categories are not related to metadata content – should be configurable from content. Action: !GeoNetwork should be able to configure dynamic categories from a Lucene field. Eg. An administrator could create category names as unique values of the Lucene field name purpose (which might be mapped to gmd:purpose for ISO) – records would belong to the category described by purpose cf. also discussion on dynamic categories ie. categories that are placeholders for a saved search. || heikki: 4 || |
| | 50 | || 28 || ||Tag cloud || GeoNetwork currently does not manage its own tag cloud / Folksonomy. Action: !GeoNetwork could optionally manage these things internally rather than using a third party social networking site. [http://trac.osgeo.org/geonetwork/ticket/96 Ticket 96 suggests a way of doing this]|| heikki: 4 || |
| | 51 | || 29 || ||Harvester / Network-crawling ||Network-crawling for geo-resources. Action: GeoNetwork needs to continue to be aware of and exploit initiatives for automatic harvesting of metadata from geo-resources. Eg. Metadata extraction tools such as the Talend Spatial Data Integrator suite etc || heikki: 3 || |
| | 52 | || 30 || ||Metadata identifier ||!GeoNetwork lacks the ability to consistently reproduce a unique identifier for the same geo resource (e.g. same dataset stored in two different locations) and/or use persistent identifier services. This is somewhere along the range from "easy enough" to "very difficult", need to spell out the precise details of the set of features you have in mind. Action: GeoNetwork needs to be able to generate, store and use metadata identifiers (eg, gmd:fileIdentifier) as well as data identifiers using the current stand alone UUID, but also (for data objects) MD5 (including what the checksum was generated from) and identifiers from external persistent identifier services (It should be possible to obtain persistent identifiers for both metadata and data from external persistent identifier services). || heikki: 4 || |
| | 53 | || 31 || ||Interoperability / resources discovery||Better inter-application interoperability. GeoNetwork needs to rethink the interoperability with the emerging FOSS such as the way that OpenLayers is designing / redeveloping its interface. e.g. use of GeoExt; e.g. GeoNetwork needs to provide simple mechanisms to allow discovered resources to be exploited and utilised in complementary open source software; e.g. drag-and-drop discovered resources into OpenLayers or GeoServer. Action: Better intra-application interoperability. GeoNetwork needs to coordinate the discovery of resources with the publication of those same resources in FOSS such as GeoServer. || heikki: 2 || |
| | 54 | || 32 || ||Data management ||!GeoNetwork assumes resources that are tagged as data for download in gmd:protocol are local. Action: GeoNetwork needs to allow for the fact that data tagged as data for download may not be local. || heikki: 1 || |
| | 55 | || 33 || ||Remote search||Remote search across a number of sites returns a pre-selected number of hits from all remote sites (pre-selected number is a search option) – it should return these hits from each site. Action: Presentation of pre-selected number of hits from each remote site – may require more delving into JZKit. || heikki: 3 || |
| | 56 | || 34 || ||Remote search||Presentation of returned hits from remote sites may be very slow because search is limited by the speed of the slowest site. Action: Presentations of first returned hits from first responding remote site should not have to wait on the slowest site – may require more delving into JZKit. || heikki: 3 || |
| | 57 | || 35 || ||Configuration||There are too many configuration files in too many places eg. repositories.xml.tem and not all configuration options are supported by the existing admin interfaces. Action: Continue to consolidate configuration options in the system configuration interface. || heikki: 2 || |
| | 58 | || 36 || ||Web map client|| There is no documentation for the implementation of alternative web map clients to Intermap and this makes it appear that the process is far harder than it actually is. Given the enthusiasm for an OpenLayers-based interface, what "interface" there currently is will probably soon be rapidly-evolving - if not replaced completely. Action: Document the interface that GeoNetwork uses to call a web map client so that sites can substitute their own.|| heikki: 1 || |
| | 59 | || 37 || ||Distributed search||Current capability of !GeoNetwork to use distributed searching is given a low priority and not being developed when compared with the local search. Action: More consideration is required towards distributed searches and proper attention should be given to it.|| heikki: 2 || |
| | 60 | || 38 || ||Distributed CSW search|| Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented. || heikki: 1 || |
| | 61 | || 39 || || XML validation|| Potential for remotely accessed information to be malicious. Action: !GeoNetwork should validate all XML inputs and responses (eg. as it does for CSW) and check expected MIME types e.g. you ask for a GIF, you get a GIF. And indicate / reject non-conforming content with a warning?|| heikki: 1 || |
