[GeoNetwork-devel] Remote search; use of repositories.xml

[Software I. gn-d. <gn-...@so...>]

The remote search functionality is currently "hidden
away" in main-page.xsl and elsewhere;
I need it, so I've been
using "main.home?intermap=off&remote=on&extended=on"
to make it visible in my browser.

I guess remote searching is not going back into
the trunk soon (or is it?), so the following is not in any
way urgent - I report this here because it
matters to me . . .

I spent some time scratching my head trying to figure
out the meaning of repositories.xml - it is not
obvious!

In the repositories.xml(.tem) file supplied with GN,
there are exactly the same number of "Collection",
"Repository", and "Instance" elements, and
the instance_dn, collection_dn, and repository_dn
attributes match up beautifully byte-for-byte.

I think this hides an error in main-page.xsl.

 From my reading of the JZKit source code (and the
GN code which uses JZKit) it seems that Z39.50 remote
searching is only by "Collection", not by "Instance".
The idea is that a "Collection" may be accessible
from more than one "Repository" - for each
"Collection", there will be one or more "Instance"s
of "Repository"s (Z39.50 servers) that can be used
to search that "Collection".  (It turns out the JZKit
code always uses the last "Instance" when choosing
a "Repository" to connect to to search a "Collection".
For the record, this is in the second createTask()
method of
jzkit/src/com/k_int/hss/HeterogeneousSetOfSearchable.java.)

JZKit does not appear to support
searching "Instance"s, only "Collection"s.

So the GN remote search page should present a list of
the "Collection"s, _not_ a list of "Instance"s,
and the <servers> values sent back by the search
form (which are passed on to JZKit) should be the
collection_dn values, not the instance_dn values.

If I'm right, the attached patch should do the
trick.  As I said earlier, this makes absolutely no
difference to the generated HTML search page
_at the moment_ because everything in the supplied
repositories.xml.tem file matches up so perfectly.

If I'm wrong, I must be _really_ confused - someone
please enlighten me!

-- 
Richard Walker
Software Improvements Pty Ltd
Phone:  +61 2 6273 2055
Fax:  +61 2 6273 2082