Changes between Version 3 and Version 4 of FCS-Aggregator

Timestamp:

04/28/11 10:57:54 (13 years ago)

Author:

vronk

Comment:

--

FCS-Aggregator

@@ -11 +11 @@
 Currently the instance connects to a number of libraries (set up in `edu.xml`).
 
+=== Conformance issues ===
 So the next step would be to adapt the configuration, so that it reads our search services.
 I tried to connect to the [http://lux17.mpi.nl/ds/annex/CQLServlet Annex/Trova SRU-interface],
-but I keep getting errors. I also tried to connect via `yaz-client` (simple console client from the Zebra/yaz-suite), which also keeps complaining. One error message among others is `Content type does not appear to be XML` and indeed all the answers from the ''annex-sru''-service are `mime-type: text/plain`. So this would be the first thing to change. However also when tried with our internal sru-service-prototype, which at least delivers the result as `text/xml`, I still got errors. I even tried to return the [http://z3950.loc.gov:7090/voyager?operation=explain explain-response from LoC-SRU] - to no avail. In general we would need better ways of debugging the connection.
+but I keep getting errors. I also tried to connect via `yaz-client` (simple console client from the Zebra/yaz-suite), which also keeps complaining. One error message among others is `Content type does not appear to be XML` and indeed all the answers from the ''annex-sru''-service are `mime-type: text/plain`. So this would be the first thing to change. However also when tried with our internal sru-service-prototype, which at least delivers the result as `text/xml`, I still got errors. I even tried to return the [http://z3950.loc.gov:7090/voyager?operation=explain explain-response from LoC-SRU] - to no avail. 
 
-One starting point is the [http://www.loc.gov/standards/sru/specs/base-profile.html SRU Base Profile], which specifies the minimal requirements, however this is of little help for the real debugging, to find which little piece is jamming.
+It also seems to be a problem to have multi-level path to the service. `yaz` interprets everything after the port as a databasename and escapes slashes. So as next debugging step we should try a base-uri that hase only single-step path.
+
+In general we would need better ways of debugging the connection. One starting point is the [http://www.loc.gov/standards/sru/specs/base-profile.html SRU Base Profile], which specifies the minimal requirements, however this is of little help for the real debugging, to find which little piece is jamming.