Changes between Version 26 and Version 27 of Bolsena2010


Ignore:
Timestamp:
Apr 1, 2010, 9:31:39 PM (14 years ago)
Author:
simonp
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Bolsena2010

    v26 v27  
    5252 * 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.
    5353
    54  * 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.
    55 Harvesting of fragments from authentication directories (eg. LDAP) should be added.
    56 
     54 * 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.
    5755
    5856 * 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.
    … …  
    6664"These Lucene fields must be indexed as default so that any search of these fields will return the appropriate response. This will automatically provide interoperability for the distributed searches.  Which fields are searched can be determined by the interface that is used to allow the user to enter search terms. If a particular field is not to be allowed as searchable by the interface then that field is not provided in the GUI. However, the Lucene indexes must still include that field so that other interfaces can search that field.
    6765GeoNetwork should use 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.
    68 
    6966
    7067 * 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.
    … …  
    8986 * 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.
    9087
    91  * 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.
    92 CSIRO: Supported by RW
     88 * 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.
    9389
    94 Continue to consolidate configuration options in the system configuration interface.
     90 * 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.
    9591
    96 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.
    97 AIMS: Would like to see this as an above average priority
    98 SoftImp: Agreed. However, given the enthusiasm for an OpenLayers-based interface, what "interface" there is will probably soon be rapidly-evolving - if not replaced completely.
    99 Document the interface that GeoNetwork uses to call a web map client so that sites can substitute their own.
    100 Current capability of GeoNetwork to use distributed searching is given a low priority and not being developed when compared with the local search.
     92 * 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.
    10193
    102 More consideration is required towards distributed searches and proper attention should be given to it.
    103 Distributed CSW searches are not available.
    104 All OGC CSW standards and specifications should be implemented.
     94 * Distributed CSW searches are not available. Action: All OGC CSW standards and specifications should be implemented.
    10595
    106 Potential for remotely accessed information to be malicious.
    107 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?
     96 * 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?
    10897
    109 Indexing slows as large numbers of records are ingested.
    110 AIMS: Agree. What is a “large” number of records out of interest?
    111 Lucene needs to be optimised for initial ingestion / indexing of multiple records – this is a potential scalability issue.
     98 * GeoNetwork does too much expensive processing of XML documents with XSLT. Action: Continue to seek out and remove unnecessary XSLT processing.
    11299
    113 GeoNetwork does too much expensive processing of XML documents with XSLT.
    114 Continue to seek out and remove unnecessary XSLT processing.
     100 * The way that GeoNetwork handles timeouts to remote requests is not configurable. Action: In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface.
    115101
    116 The way that GeoNetwork handles timeouts to remote requests is not configurable.
    117 In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface.
     102 * Developments in "sand boxes" are not pushed back into the trunk in a timely manner. Action: The PSC should publish and enforce tighter processes relating to sandboxes. If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above).
    118103
     104 * GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code.
    119105
     106 * Theere is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container.  Jetty should continue to be the default.
    120107
    121 Developments in "sand boxes" are not pushed back into the trunk in a timely manner.
     108 * Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component.  Perhaps provide a way to limit results to only parents and toggle this option on/off.
    122109
    123 CSIRO: Supported by RW
    124 SoftImp: Agreed. The PSC should publish and enforce tighter processes relating to sandboxes.
    125 If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above).
    126 GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins.
     110 * 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.
    127111
    128 AIMS: Skinning will help with roll out to agencies with less technical skills.  Branding is important.
     112 * 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.
    129113
    130 GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code.
     114 * 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.
    131115
     116 * 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.
    132117
     118 * EPSG code data from external service Action: At the moment EPSG codes have to be entered manually, but external online services are available with that data. GN should utilize this.
    133119
    134 
    135 
    136 
    137 
    138 
    139 
    140 
    141 
    142 The installer does not provide the option to choose Tomcat and an alternative to Jetty.
    143 
    144 AIMS: Agree
    145 SoftImp: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation.
    146 
    147 
    148 
    149 
    150 
    151 
    152 
    153 
    154 GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container.  Jetty should continue to be the default.
    155 
    156 Additional Comments
    157 Parent/child/sibling bidirectional navigation for metadata records
    158 Finding the parent or child of given record is painful
    159 Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity.  For example, listing all children under the parent and presenting this within a collapsed tree GUI component.  Perhaps provide a way to limit results to only parents and toggle this option on/off.
    160 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.
    161 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.
    162 Support for external vocabulary services
    163 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. An interface is required to query for vocab definitions from external sources
    164 Reusable (Controlled) Objects, allow fields to be reusable
    165 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
    166 HTTPS support
    167 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.
    168 EPSG code data from external service
    169 At the moment EPSG codes have to be entered manually, but external online services are available with that data. GN should utilize this.
    170 
    171 Hierarchical keywords
    172 Keywords from external vocabularies (see item 35) should utilize hierarchical broader/narrower structures to ease searching capability.
     120 * Hierarchical keywords. Keywords from external vocabularies should utilize hierarchical broader/narrower structures to ease searching capability.
    173121
    174122