| 64 | | || 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 || Is it possible to make it abstract in order to extend to other protocols ? |
| 65 | | || 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 || This 'feature' is not present in JZKit3 and remote search has been restored in version 2.7 (see [[wiki:RemoteSearchForm%2BTabbedSearchForms]]. || |
| 66 | | || 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 || eg. Z39.50 repositories || |
| 67 | | || 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 | jose: critical || |
| 68 | | || 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 || |
| 69 | | || 38 || ||Distributed CSW search|| Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented. || heikki: 1 || |
| 70 | | || 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 || |
| 71 | | || 40 || ||Perfs enhancement (XSL)|| !GeoNetwork does too much expensive processing of XML documents with XSLT. Action: Continue to seek out and remove unnecessary XSLT processing.|| heikki: 4 || |
| | 64 | || 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 || Is it possible to make it abstract in order to extend to other protocols ? Possibly - awaits further investigation of JZKit3 || |
| | 65 | || 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 || This 'feature' is not present in JZKit3 and remote search has been restored in version 2.7 (see [[wiki:RemoteSearchForm+TabbedSearchForms]]. || |
| | 66 | || 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 || This is ongoing. || |
| | 67 | || 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 | jose: critical || Intermap has been replaced with OpenLayers - the functions that manipulate the OpenLayers client still need to be documented. || |
| | 68 | || 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 || Restored in 2.7 - see [[wiki:RemoteSearchForm+TabbedSearchForms]] || |
| | 69 | || 38 || ||Distributed CSW search|| Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented. || heikki: 1 || May be related to issue 33 || |
| | 70 | || 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 || No progress as yet. || |
| | 71 | || 40 || ||Perfs enhancement (XSL)|| !GeoNetwork does too much expensive processing of XML documents with XSLT. Action: Continue to seek out and remove unnecessary XSLT processing.|| heikki: 4 || Ongoing - note that caching of compiled XSLT makes this less expensive || |
| 77 | | || 46 || ||Search||Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful). Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. || || |
| 78 | | || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || heikki: proposes OWL/ebRIM integration, see [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/] || |
| | 77 | || 46 || ||Search||Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful). Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. || || This issue is not unique to GeoNetwork. || |
| | 78 | || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || heikki: proposes OWL/ebRIM integration, see [http://geonetwork.tv/owl/ http://geonetwork.tv/owl/] || These interfaces are slowly becoming available - see for example the taxonomic species name searching for the Marine Community Profile records in ANZMEST || |
| 80 | | || 48 || ||Reusable Objects || Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above.|| heikki: 3 || See composed metadata records |
| 81 | | || 49 || ||HTTPS support || HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks.|| heikki: 2 || To be checked, Maybe the download URL set to http by default ? || |
| | 80 | || 48 || ||Reusable Objects || Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above.|| heikki: 3 || See composed metadata records proposal committed in 2.5 (see ticket #201) || |
| | 81 | || 49 || ||HTTPS support || HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks.|| heikki: 2 || URLs are hard coded with http in a number of places in GeoNetwork - see ticket #448 || |
| 85 | | || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| heikki: 3 || Good idea ! || |
| 86 | | || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk. || heikki: 5 || Available in Bluenet |
| | 85 | || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| heikki: 3 || Done in 2.7 || |
| | 86 | || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk. || heikki: 5 || Available in Bluenet being ported to trunk for 2.7 || |
