[Koha-devel] New Search (rel_3_0) in question

[Henri-Damien LAURENT]

Hi,
I am trying to get things together for rel_3_0 with synching dev on devweek.
It appears that the page search.pl (the advanced search) makes heavy use
of hardcoded elements which perfectly fit USMARC but are useless for
UNIMARC.
Moreover, it relies on coded fields which are supposed to be mandatory,
but most of the time, our custommers will overlook them and not fill
them in. So this raises some problems to us.
First, Up 'till now, itemtypes for instance were user defined. But with
using such search, there would be some kind of "itemtypes" (see
Material-type or Litterature-Code or target-Audience) that would be
prompted by the system and users should change a little their way to use
the software, if I don't mind.
Second, lists should be marcflavour dependant or at least should be
processed in the Template and not in the code.

What could be proposed is to get all these things into Templates through
a loop that would parse some authorised_values.
For instance, Material-Type would be in category MTTY and would contain :

d = large print
e = newspaper format
f = Braille or Moon script
g = microprint
h = hand-written
i = multimedia (e.g. an item in regular print with a microfiche supplement)
j = mini-print
r = regular print
z = other form of textual material

for unimarc...
and for usmarc
# - None of the following
a - Microfilm
b - Microfiche
c - Microopaque
d - Large print
f - Braille
r - Regular print reproduction
   Eye-readable print.
s - Electronic
| - No attempt to code

(But I found ta, tb, fk in our code stored in 07/0-1)
A diffculty would be that where USMARC uses only one field (007),
UNIMARC uses multiple ones 110, for serials, 126 for sound recordings,
115 for motion pictures, 130 for Microforms, each one having its own
list of material type.

What I am trying to say here is that it seems to me that
- I have on the long-term to study both norms to try and make things
together
BUT
- that our customers surely donot need such a tough norm abidance but
they require that looking for a user-defined itemtype they can find it.
This I will try and code.
NEVERTHELESS,
 along with it and preparing the long-term developement, we think it may
be useful to propose strict abidance to norms. But this should be done
carefully and not with too much hardcoded lists but should be either in
templates or in database so that users could invoke this or that part of
base and it fills templates with right values. And we should settle
which categories would be searchable and which should be in database.

THEREFORE, I try and share some thoughts about that.