Changes between Version 88 and Version 89 of Bolsena2010

Timestamp:

Mar 24, 2011, 9:54:57 AM (13 years ago)

Author:

simonp

Comment:

--

Bolsena2010

@@ -53 +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. ||
  || 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. ||
- || 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. ||
+ || 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 (see ticket #409). ||
  || 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  ||
  || 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 || On going ||