wiki.met.no

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Open questions for version 2.8 ======

===== Open questions =====

  * [[better_config|Configuration issues]]

===== Answered questions =====

  * Should there be any limits on the size of the collection basket? In the terms of number of file or in the terms of size of the download. Should this be different for logged in and logged out users?
    * There must be a configurable limit of the size of the data when downloading data as archive (zip/tar). The number of items in the collection basket is not limited.
      * The first version should have one limit for subscription-users and one limit for general users.
      * The limit should only be evaluated before creating the archive.
      * As alternative, the user might get a script with a list of 'wget' commands.

  * How is it decided which metadata is displayed for the level 2 datasets in the search result. In the current implementation this varies between different datasets.
    * The metadata should be displayed in its incoming format. We might wish at a later stage to enable a view of metadata in a specific format, i.e. xmlAsISO19115 in addition to its original format. This is currently possible in oai-pmh-streams.
    * The top-level metadata is created from the latest file submissions. The metadata on the 2nd level may differ from the top-level metadata. The current PHP script checks, for all metadata elements, if all files have the same metadata value. If so (and the value is displayed on the top level), the value is not displayed on the second level. Values that varies between files are displayed. Values that are empy for all files are not displayed. The configurable limit on number of columns (SEARCH_APP_MAX_COLUMNS) is honored. If this limits what metadata are displayed, I think it is somewhat arbitrary which matadata are dropped.  --- //[[egil.storen@met.no|Egil Støren]] 2010/10/14 12:45//
      * Should SEARCH_APP_SHOW_COLUMNS be honored at level 2? That is if a column on level 2 is not shown on level 1 and has different data, should it then be displayed if the column is not found in SEARCH_APP_SHOW_COLUMNS  --- //Øystein Torget 2010/11/11 17:05//
        * It is okay to honor it. If differences only exist in invisible columns, it might be nice to show the otherwise invisible, too.  --- //[[heiko.klein@met.no|Heiko Klein]] 2010/11/19 14:14//