X-Git-Url: http://jsfdemo.indexdata.com/?a=blobdiff_plain;f=lib%2FZOOM.pod;h=73e122a870b5b9ee45675b758fc473e2f8b81a1e;hb=ae5c2b81234af64a77295188f6fc90ede3589723;hp=908bba5148e5a1c075b2f32a590966e195d5a6b8;hpb=7bf889db4a2c15b79d5ac332c09d304ace400111;p=ZOOM-Perl-moved-to-github.git

diff --git a/lib/ZOOM.pod b/lib/ZOOM.pod
index 908bba5..73e122a 100644
--- a/lib/ZOOM.pod
+++ b/lib/ZOOM.pod
@@ -1,4 +1,4 @@
-# $Id: ZOOM.pod,v 1.32 2006-04-11 16:38:38 mike Exp $
+# $Id: ZOOM.pod,v 1.37 2006-06-15 15:42:30 mike Exp $
 
 use strict;
 use warnings;
@@ -39,8 +39,8 @@ API such as ZOOM is that all implementations should be compatible
 anyway; but knowing that the same code is running is reassuring.)
 
 The ZOOM module provides two enumerations (C<ZOOM::Error> and
-C<ZOOM::Event>), two utility functions C<diag_str()> and C<event()> in
-the C<ZOOM> package itself, and eight classes:
+C<ZOOM::Event>), three utility functions C<diag_str()>, C<event_str()>
+and C<event()> in the C<ZOOM> package itself, and eight classes:
 C<ZOOM::Exception>,
 C<ZOOM::Options>,
 C<ZOOM::Connection>,
@@ -50,12 +50,13 @@ C<ZOOM::Record>,
 C<ZOOM::ScanSet>
 and
 C<ZOOM::Package>.
-Of these, the Query class is abstract, and has three concrete
+Of these, the Query class is abstract, and has four concrete
 subclasses:
 C<ZOOM::Query::CQL>,
-C<ZOOM::Query::PQF>
+C<ZOOM::Query::PQF>,
+C<ZOOM::Query::CQL2RPN>
 and
-C<ZOOM::Query::CQL2RPN>.
+C<ZOOM::Query::CCL2RPN>.
 Finally, it also provides a
 C<ZOOM::Query::Log>
 module which supplies a useful general-purpose logging facility.
@@ -97,6 +98,14 @@ C<ZOOM::Connection::errcode()>,
 irrespective of whether it is a member of the C<ZOOM::Error>
 enumeration or drawn from the BIB-1 diagnostic set.
 
+=head2 ZOOM::event_str()
+
+ $msg = ZOOM::event_str(ZOOM::Event::RECV_APDU);
+
+Returns a human-readable English-language string corresponding to the
+event code that is its own parameter.  This works for any value of the
+C<ZOOM::Event> enumeration.
+
 =head2 ZOOM::event()
 
  $connsRef = [ $conn1, $conn2, $conn3 ];
@@ -1012,6 +1021,21 @@ relations and modifiers into Type-1 query attributes.  An example CQL
 configuration file is included in the ZOOM-Perl distribution, in the
 file C<samples/cql/pqf.properties>
 
+=item ZOOM::Query::CCL2RPN
+
+Implements CCL by compiling it on the client-side into a Z39.50 Type-1
+(RPN) query, and sending that.  Because the compilation is done on the
+client side, a configuration file is required to direct the mapping of
+CCL constructs such as index names and boolean operators into Type-1
+query attributes.  An example CCL configuration file is included in
+the ZOOM-Perl distribution, in the file C<samples/ccl/default.bib>
+
+CCL is syntactically very similar to CQL, but much looser.  While CQL
+is an entirely precise language in which each possible query has
+rigorously defined semantics, and is thus suitable for transfer as
+part of a protocol, CCL is best deployed as a human-facing UI
+language.
+
 =back
 
 See the description of the C<Query> class in the ZOOM Abstract
@@ -1042,6 +1066,17 @@ if compilation fails, then diagnostic information is cached in the
 Connection and be retrieved using C<$conn-E<gt>errcode()> and related
 methods.
 
+ $conn->option(cclfile => "samples/ccl/default.bib");
+ # or
+ $conn->option(cclqual => "ti u=4 s=pw\nab u=62 s=pw");
+ $q = new ZOOM::Query::CCL2RPN('ti=dinosaur', $conn);
+
+For the C<ZOOM::Query::CQL2RPN> subclass, too, the Connection must be
+passed into the constructor, for the same reasons as when client-side
+CQL compilation is used.  The C<cclqual> option, if defined, gives a
+CCL qualification specification inline; otherwise, the contents of the
+file named by the C<cclfile> option are used.
+
 =head4 sortby()
 
  $q->sortby("1=4 >i 1=21 >s");
@@ -1218,6 +1253,10 @@ C<TIMEOUT>,
 C<UNSUPPORTED_PROTOCOL>,
 C<UNSUPPORTED_QUERY>,
 C<INVALID_QUERY>,
+C<CQL_PARSE>,
+C<CQL_TRANSFORM>,
+C<CCL_CONFIG>,
+C<CCL_PARSE>,
 C<CREATE_QUERY>,
 C<QUERY_CQL>,
 C<QUERY_PQF>,
@@ -1377,12 +1416,12 @@ The approach is as follows:
 
 Create several connections to the various servers, each of them having
 the option C<async> set, and with whatever additional options are
-required - e.g. setting the piggyback retrieval record-count so that
-records will be returned in search responses.
+required - e.g. the piggyback retrieval record-count can be set so
+that records will be returned in search responses.
 
 =item Operations
 
-Send searches to the connections, request record retrieval, etc.
+Send searches to the connections, request records, etc.
 
 =item Event harvesting
 
@@ -1391,21 +1430,22 @@ received from the servers.  Each time this function returns, it
 indicates which of the connections has fired; this connection can then
 be interrogated with the C<last_event()> method to discover what event
 has occurred, and the return value - an element of the C<ZOOM::Event>
-enumeration can be used to determine what to do next.  For example,
-the C<ZEND> operation indicates that no further operations are
+enumeration - can be tested to determine what to do next.  For
+example, the C<ZEND> event indicates that no further operations are
 outstanding on the connection, so any fetched records can now be
 immediately obtained.
 
 =back
 
 Here is a very short program (omitting all error-checking!) which
-demonstrates this process.  It parallel-searches two servers (or more
+demonstrates this process.  It parallel-searches three servers (or more
 of you add them the list), displaying the first record in the
 result-set of each server as soon as it becomes available.
 
  use ZOOM;
  @servers = ('z3950.loc.gov:7090/Voyager',
-             'bagel.indexdata.com:210/gils');
+             'bagel.indexdata.com:210/gils',
+             'agricola.nal.usda.gov:7190/Voyager');
  for ($i = 0; $i < @servers; $i++) {
      $z[$i] = new ZOOM::Connection($servers[$i], 0,
                                    async => 1, # asynchronous mode