CORDRA: Content Object Repository Discovery and Registration/Resolution Architecture

Search Interface Protocols and Specifications

Document Information

Abstract

There are several available interface specifications, protocols and APIs for repository search and information retrieval. This document compares key characteristics of these to inform selection or profiling of one or more of these specifications for use within a CORDRA&trade implementation or within Federated CORDRA.

Introduction
Search Specifications
Search Interface Specification Comparison
CORDRA Requirements Summary
References

Different search interface and protocol specifications are based on different models and have different capabilities. Select, major alternatives are compared in order to identify common features and variations between approaches. These are also compared to core requirements for CORDRA. As applicable, one or more of these specifications might be selected and profiled to provide a search interface to the registry of a CORDRA implementation or to provide a search interface for Federated CORDRA.

This document compares five different specifications used in digital libraries and web search. The comparison is based on public documents included as part of the official document collections for each specification, as listed below. Additional application profiles or third-party descriptions outside of the formal document set are not included in the comparision.

SQI [SQI, SQI Sessions, SQI LORI]
SRW/SRU [SRW, CQL, Zing, ZeeRex, Zoom, Z39-50]
OpenSearch [OpenSearch]
Google Web Service API [Google]
OAI-PMH [OAI]

Search Specifications

Simple Query Interface (SQI) is an API-oriented interface for query of (learning) content repositories [SQI]. It is a session-based protocol for passing queries and results between a requesting client and a data provider. It is designed to be independent of query language and results format, and can support both synchronous and asynchronous return of results. It includes an optional simple authentication specification [SQI Sessions]. The overall model is separated from both (1) the bindings to data representations for query and results (e.g., XML, plain text) and (2) the messaging protocols (e.g., SOAP, RPC, RMI). A profile of SQI with associations for data representations and messaging is required to implement an SQI interface between a client and data provider.

Search/Retrieval Webservice (SRW) / Search/Retrieval by URL (SRU) is an XML-based protocol for information retrieval [SRW]. Its development was motivated, in part, to provide a web-oriented protocol similar to Z39.50 [Zing, Z39.50]. It is a message-oriented protocol for passing queries and results between a requesting client and a data provider. It is designed to be used with a specific query language ([CQL]) but can support any results format. It defines synchronous messaging without authentication or session controls. The model is explicitly bound to XML data representations and web services or REST messaging models.

OpenSearch is a simple, web-based search mechanism that returns results in RSS format [OpenSearch]. The focus is on using RSS (with extensions) and other existing specifications as a way to "publish" search results such that they can be further syndicated and accessed by commonly available tools. OpenSearch uses its own query format transferred via HTTP. Returned results are rendered in XML in extended RSS 1.0.

Google Web Service API

The Google Web Service API provides a SOAP interface to Google [Google]. It provides an XML format for queries, using Google's query language and a Google-specific XML format for results. It is a synchronous message-oriented protocol, with messages defined in WSDL and communicated with SOAP. While specific to Google, the same API model and service definitions could be used with any data provider.

Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) is an XML-based protocol for metadata information retrieval (harvesting) [OAI-PMH]. It is a synchronous messaging protocol, transmitted over HTTP (a REST style interface). It uses a fixed set of protocol requests. Results are returned in XML and conform to OAI-PMH XML Schema XSDs. Individual record results may be in any format. Certain aspects of the protocol are left to application profiles or agreements between clients and data providers established within a community of practice.

Search Interface Specification Comparison

The five alternatives are compared on several key characteristics important in the development of the CORDRA model (the order of presentation is not significant).

Throughout most of the remainder of the feature comparison, the analysis will focus on features within individual layers in the abstract model described below. While the features are described individually, there are natural overlaps and connections among the features such that choices for one may influence the design and implementation of others.

Some aspects of the specifications have been simplified for comparison purposes. As noted, the comparisons are based only on public documents describing the specifications. Additional characteristics from actual implementations, practice, application profiles, etc., were not considered in the comparisons.

An overall abstract model for search and retrieval services can be represented as a set of abstraction layers (patterned after the SQI Learning Object Repository Interoperability Stack [SQI LORI]). Blank entries are not defined within the specification. Items marked "application profile" require additional specifications or a profile of the specification to define a complete interoperable system between the requesting client and the data provider. Such application profiles are not defined as parts of the specifications themselves.

Abstraction Layer	SQI	SRW	OpenSearch	Google API	OAI-PMH
Semantic Model (Data Model, Representation)	Application Profile	XML, CQL	RSS 1.0 / Data provider specific	Google Query, XML	XML, OAI
Services and Protocols	Sync/Async Search & Retrieve	Sync Search & Retrieve, Browse, Discovery	Sync Search & Retrieve, Discovery	Sync Search & Retrieve	Sync Harvest Request & Retrieve, Discovery
Common Services (Sessions Management, Authentication, Authorization)	Sessions, Authentication			Google ID
Messaging (REST, SOAP, RPC, RMI)	Application Profile	REST, SOAP	REST	SOAP	REST
Network Transport					HTTP

SQI. SQI is designed as a simple abstract model for query and response messages. Bindings to data models and messaging are not part of the model or specification but are deferred to profiles and additional specifications (e.g., the Common SQI WSDL Binding [SQI WSDL]). However, the specification covers two layers in the general model above by combinding an explicit session model and inclusion of authentication with the service protocols. Part of this combination seems unavoidable since the overall SQI model is oriented around, and coupled to, sessions.
SRW/SRU. SRW is a complete service, messaging, transport and data binding model without session controls or authentication. The specification covers three layers in the general model above. The basic model can be abstracted from the XML bindings and messaging protocols (the separation of SRW from SRU, each built on top of the core services and search/retrieve protocols, illustrates such an uncoupling). Zoom [Zoom] also presents a more abstract model underlying Z39.50.
OpenSearch. OpenSearch is targeted at producing RSS results from specific data providers. The specification has no formal model and covers three layers in the general model above. The data models, query language and results formats are not part of the model. Application profiles and additional specifications could be used to define and further detail the use of OpenSearch, but the specification focuses on simple results federation rather than supporting a complex query interface.
Google API. The Google API is designed to provide a SOAP interface to Google. The API specification has no formal model, but covers three layers in the general model above. Google-specific data formats and a version of Google's query language are defined in the API specification. A generalized model could be abstracted from the API specification by generalizing the format of the query language or results set.
OAI-PMH. OAI is a complete service, messaging, transport and data binding model. The specification covers four layers in the general model above, including specific requirements on the HTTP transport. Some aspects (results set representations) are independent of the model and are defined in application profiles and other specifications. The basic model could be abstracted from the XML bindings and messaging protocols.

The complete CORDRA model for a community of practice or CORDRA implementation requires specifications for all parts of the abstract model. Having separable models and composable layers of specifications is desirable.

Web Orientation and Web Architecture

Core web architecture and successful scalable implementations are based on several characteristics, including an orientation towards large-grained, document-focused transactions implementable over stateless, cacheable messaging, and URI-based identification.

SQI. As defined, SQI is essentially an RMI-based (remote method invocation) protocol. SQI is based on object-oriented paradigms, combined with URI-based identification of a few key data elements. Based on the "Command-Query Separation Principle," it favors the separation of messages for commands from the messages for queries. Maintaining this model in the messaging layer requires a stateful, session-oriented protocol, and session information is thus embedded in all parts of the protocol. Likewise, the decision to implement a simple command set results in a large number of separate messages in the protocol. The potentially "chatty" nature of the SQI protocol (resulting from a large number of messages) combined with the need to save state across all sessions may imply a performance problem when trying to scale the number of requests sent to a data provider. SQI could be implemented through a seperate messaging level by combining API calls into stateless messages. In this approach, applications would use the SQI API to communicate, but the approach requires an independent messaging model and specification for interoperable communications. The approach seems to contradict the basic edicts of the SQI model.
SRW/SRU. SRW's design is based on a (web) services model (but this model is not explicit in the specification). The current web services model is not described using the full WS-* set of interoperability specifications, but SRW is designed to be compatible with the WS-* specifications (only SOAP is required, but WSDL definitions are available). XML documents are used to encode requests and for the returned results. URI-based identification is used throughout.
OpenSearch. OpenSearch is based on a REST model (but this model is not explicit in the specification) combined with RSS formats. Simple HTTP get requests are used for query. RSS with extensions are used for results. URIs are not used in the specification, but some items in describing a data provider are defined as URLs.
Google API. The Google API is based on a web services model using SOAP and WSDL (but this model is not explicit in the API specification). The web-services model is not based on the full WS-* set of interoperability specifications. XML documents are used to encode requests and for the returned results, but the XML document formats are not defined in XML Schema XSDs. URI-based identification is not used.
OAI-PMH. OAI is based on a REST model using both HTTP get and post (but the model is not explicit in the specification). The OAI specification includes requirements on the HTTP transport. XML documents are used to encode requests and for the returned results. XML document formats are defined by, and must conform to, XML Schema XSDs. URI-based identification is used in part of the model.

While CORDRA does not have a requirement for explicit web orientation in the specifications selected, a web-oriented approach is preferred for scalability and performance. Services should be focused on document exchange. Messages should be cacheable. URI-based identification throughout is required.

We expect that the specifications and repository interfaces will evolve, with new versions incorporating different features and behaviors. Requesting clients and data providers may implement different versions of a protocol.

SQI. SQI does not include any versioning features. Clients and providers may agree to use specific versions of the protocol or may negotiate version compatibility via some non-specified, out-of-bound method or protocol. Alternatively, a profile of the API may include versioning as a profile-specific extension to the overall protocol or through its inclusion in the messaging layer; however, different versions may not be interoperable.
SRW/SRU. SRW includes version information in requests and responses in the overall protocol model and has a defined behavior for negotiating between the client and data provider which version to use.
OpenSearch. OpenSearch does not include any versioning information in the protocol and does not define version negotiation. RSS version information is included in the message results along with namespace information specific to the OpenSearch version.
Google API. The Google API does not define versioning information in the protocol. No version information is included in results.
OAI-PMH. OAI does not include any versioning information in requests or responses. Information about the version of the protocol that a repository supports is provided in the repository discovery information. The client must use the version of the protocol advertised by the data provider.

CORDRA will require versioning of all services at the services or protocol level. Version information will need to be carried forth into the messaging layer.

Session Management

Session management provides for stateful services where all elements of a request or response do not need to be included within a single message.

SQI. SQI is designed to be used as a session-oriented protocol with multiple messages and queries per session (based on the underlying requirements from the "Command-Query Separation Principle"). As such, when each API message is implemented as a separate transport message, it is a stateful protocol. Details of session behavior (e.g., timeouts, session durations) are left to application profiles or private agreements between clients and data providers. There are no explicit QoS guarantees, i.e., a session may terminate before all messages needed to make a request have been processed. The SQI authentication and session management specification [SQI Sessions] is a component of the SQI set of specifications that can be used to establish sessions.
SRW/SRU. SRW is a stateless protocol. Sessions are not supported nor are they needed. SRW services could be layered within a session-oriented protocol if needed, through an application profile or additional specification. A data provider may provide QoS estimates in results sets.
OpenSearch. OpenSearch is a stateless protocol. Session information could be defined with a separate model, but the query protocol does not define the behavior if a request includes information such as session data.
Google API. The Google API is a stateless protocol. Sessions are not supported.
OAI-PMH. OAI is a stateless protocol. Session information could be defined with a separate model, but the protocol does not define the behavior if a request includes information such as session data. A data provider may provide QoS estimates in results sets.

There are no current CORDRA requirements for session-oriented search and retrieval services. While a community or implementation may choose to implement session-oriented models within their federation, this is not a requirement. Providing QoS information would be useful in operations.

Authentication and Authorization

Authentication and authorization (combined with separate identity management) may be important for some registries and federations to control access to query services and results.

SQI. SQI includes an optional simple userid/password-based authentication method that is incorporated with session control and initiation services. Other than the initial authentication used to create a session, SQI does not specify any other authentication or security requirements. An application profile or specification of the messaging protocols is needed to define a complete authentication and authorization model.
SRW/SRU. SRW does not include an authentication model. SRW can be combined with a separate authentication and authorization model defined through an application profile or other specification.
OpenSearch. OpenSearch does not include an authentication model. Authentication information could be defined with a separate model, but the query protocol does not define the behavior if a request includes authentication or authorization information.
Google API. The Google API does not include an authentication model. Google API clients must have a license key (obtained through an external process) that is included in all requests. The license key is used to limit and throttle client access.
OAI-PMH. OAI does not include an authentication model. OAI can be combined with a separate authentication and authorization model defined through an application profile or other specification.

Individual CORDRA implementations may require authenticated and authorized query services. Models for authentication and authorization must remain uncoupled from core definitions of query services and protocols. It also must be possible to combine authentication and authorization data within the messaging layer independent of the service definitions. CORDRA requires additional specifications and specification profiles for authentication and authorization.

Stateless Query Transactions

Independent of maintaining session state overall, individual query transactions might be stateful or stateless, i.e., if a part of the results set is returned, a request for the next part will use the same results set in a stateful transaction model while a stateless query service will need to regenerate the entire results set.

SQI. SQI transactions may be either stateful or stateless, as determined by the implementing data provider. Except for external statements by the provider or application profiles, there is no mechanism to determine if a query service is stateful or stateless or if there are any definitions for the model applied to results sets. One should not assume consistency between requests for partial results from the same query (e.g., the query for results 1-10 and the results 11-20 may not return the same values as a single query for results 1-20).
SRW/SRU. By default, all results are stateless. A data provider may indicate an intention that a results set will be maintained. As with SQI, the data provider controls when results sets are obtained or destroyed, but the protocol provides the mechanism for the client to know when the results set is maintained. SRW defines a formal model for results set behavior when stateful query transactions are supported, so that all implementations will behave in a predictable way.
OpenSearch. The OpenSearch specification makes no statements about results sets or maintenance of state. Since there is no session model and results do not include results set descriptions, there is no defined mechanism to maintain state across queries. RSS user clients may maintain RSS feed information for further syndication.
Google API. The Google API makes no statements about the management of results sets or the maintenance of state. Since there is a license key associated with a request, sufficient information is available to maintain state and process multiple queries against a single results set.
OAI-PMH. OAI transactions may be either stateful or stateless, as determined by the implementing data provider. Except for external statements by the provider or application profiles, there is no mechanism to determine if a service is stateful or stateless. OAI defines a formal model for results set behavior when partial results are returned through the defined flow control mechanism. Flow control can be implemented in either stateless or stateful transactions and all implementations will behave in a predictable way.

There are no CORDRA requirements for stateful query transactions. Given the dynamic nature of the registry, an expectation of consistency between subsequent queries is unreasonable. However, implementing and caching results sets may improve performance.

If results sets are implemented, their behavior needs to be fully specified (e.g., what is the TTL, what happens when an element from the results set is deleted).

Synchronous and Asynchronous Queries

Synchronous queries provide response messages directly to query requests (one-to-one). Asynchronous queries let the data provider return multiple asynchronous responses that are merged by the requesting client.

SQI. SQI supports asynchronous queries; the requesting client may pass a call-back location to the data provider, and the provider responds with multiple messages containing the query response. SQI does not impose QoS requirements on either the data provider or client listener.
SRW/SRU. SRW defines a synchronous only request-response model.
OpenSearch. OpenSearch defines a synchronous only request-response model.
Google API. The Google API WSDL defines a synchronous only request-response model.
OAI-PMH. OAI defines a synchronous only request-response model.

There are no CORDRA requirements for asynchronous queries. While a community or implementation may choose to implement asynchronous queries within their federation, this is not a requirement.

Compared with synchronous queries, supporting asynchronous queries appears to place an additional implementation burden on both requesting clients and data providers (and force an implementation to support sessions). A separate specification or application profile to support asynchronous queries should be investigated.

Query Languages

Query languages are combined with a query request protocol to define a search interface.

SQI. SQI does not define a query language to use with the query protocol. The protocol includes a single query statement in search requests. There is no limit to the potential complexity of the query language and the features it might support. An application profile of the specification is needed to specify the query language(s) used within an implementation.
SRW/SRU. SRW uses CQL as the single available query language [CQL]. Since CQL does not provide an ordering or sorting function, the protocol includes additional parameters to order results. SRW also includes the ability to select a portion of each query result through filtering with an XPath statement. While the SRW specification links CQL to SRW, the overall search service protocol is not tied to CQL, with the exception of SRW needing to support additional specifications for filtering and ordering that are not part of CQL.
OpenSearch. OpenSearch does not define a query language. It supports a simple query string as part of the protocol. Query complexity is limited to what can be URL-encoded within an HTTP get request.
Google API. The Google API uses a version of Google's own query language. The query request protocol includes the query string and additional filtering and request (restriction) data that is not part of the query string. Query complexity is limited to a predefined length limit.
OAI-PMH. OAI supports a fixed number of requests, each with a set of specific request parameters.

A CORDRA implementation must select one or more query language specifications for use within a federation. Defining the query language seperately from the service protocol provides flexibility. However, supporting multiple query languages may result in more complex specifications and will likely result in more complex implementations.

The requirements for a CORDRA query language are not yet specified. General query characteristics such as keyword and index matching, Boolean operators, etc., are most likely important, as is ordering of results. Results filtering might be useful, but like ordering, having the data provider perform the operation instead of deferring it to post-query processing by the requesting client is primarily an optimization in search and data transfer. Such optimizations minimize the work and complexity of the requesting client and may improve performance of the search process.

There is no common model for representing all of the aspects of a query (string, operators, filtering, ordering). Having a common model would aid in interoperability across CORDRA implementations that use different query languages and query service protocols.

Query results present the set of information returned to the requesting client in response to query processing.

SQI. SQI provides a method to set the "format" of the query result. It appears that this is the per record data schema, i.e., each individual result is presented according to the defined schema. The specification of how all of the individual results are combined into the entire results set and the format of the entire results set are not specified by the SQI services, but are left to an application profile. Thus, for example, there is no common result format to determine the number of results from a single query. SQI does not address how the results schema is used, i.e., is it a formatting or structural schema for the record, or can it be used to transform the internal data structure in the repository to any defined format (e.g., map the results to DC, LOM, MARC, ...).
SRW/SRU. SRW provides a query attribute used to set the format of the query result. The format is not only the structural format of the XML, but it also defines a single corresponding metadata model (e.g., DC, MODS, MARC); internal data structures of the data provider are transformed to the requested format and data model for return to the requesting client. The specification includes a definition of the overall record set format returned in the response. Query results also include the size of the returned results set. Additional search control attributes can be used to provide additional results formatting and optimizations, including defining styles applied by the data provider or record set encoding.
OpenSearch. OpenSearch provides results in a defined RSS format for the overall results sets. Individual elements are RSS elements in the overall RSS feed, but the specification does not define how the details of individual search results are represented as RSS. OpenSearch recommends how some results are encoded with XML fields in the RSS field.
Google API. The Google API defines Google's particular XML results format embedded in the SOAP message. The results format includes control data, the set of query records (each in XML) and associated results data.
OAI-PMH. OAI provides an attribute used to set the format of the harvest result. The format is not only the structural format of the XML, but it also defines a single corresponding metadata model (e.g., DC, MODS, MARC); internal data provider data structures are transformed to the requested format and data model. The specification includes a definition of the overall record set format returned in the response. Results also include the size of the returned results set and information about flow control.

A CORDRA implementation may need to support multiple query result formats (both semantically and structurally different forms). The ability to define the query result format independent of the service protocol provides flexibility at the cost of a more complex set of specifications and a more complex implementation if multiple result formats and data model translations are supported. Defining a results set as both a known set of control information (e.g., results set size) and the collection of results may simplify processing by the requesting client.

The requirements for the results set formats supported by an implementation are unique to that implementation and are not yet specified.

There is no common model to represent the different characteristics of a results set (overall format, individual result format, formatting, size and control paramenters). Having a common model would aid in interoperability across CORDRA implementations that use different query results formats.

Protocol and Repository Information Discovery

Various defaults and protocol control parameters are defined for both the protocol and specifications overall and as implementation characteristics of individual data providers.

SQI. The SQI specification details particular aspects of the protocol and parameters that constrain default behavior. These are not machine readable. Additional values or changes may be specified in application profiles.
SRW/SRU. Critical control parameters of a data provider are maintained by the data provider and available to the requesting client through an Explain query [ZeeRex]. The values obtained are definitive in understanding the behavior of the protocol or a data provider.
OpenSearch. OpenSearch defines an XML representation for a data provider (via a textual description - there is no XML Schema XSD). The description must be published at a known URL that is registered within the central OpenSearch registry. Registration data also includes the target location for search queries.
Google API. Since the API is specific to Google, the documentation and associated provided WSDL fully defines the query services and results.
OAI-PMH. A description of the data provider is available to the requesting client through an Identify request. The XML format of the response is described by an XML Schema XSD that is maintained within an application profile of the specification developed for a particular community. Other requests and defined results formats are used for additional discovery (supported metadata formats and cataloging).

The design of CORDRA favors self-descriptive systems and the ability to automatically discover and configure clients and servers. While this imposes an additional implementation overhead, it improves interoperability as these parameters and the processing systems can be adjusted on demand without requiring changes to the underlying specifications to set new values or without negotiating the parameters via separate specifications or out-of-bound methods.

Extension Mechanisms

A query specification cannot be expected to be complete and meet the needs of all communities. Extension mechanisms provide a way to adapt and extend the specification to meet additional or unforeseen requirements without developing a new version of the specification.

SQI. SQI does not include an extension mechanism. Additional features require new services, message formats and API calls.
SRW/SRU. SRW has a simple built-in extension mechanism for passing additional XML data as part of a request and getting additional XML formatted data in the result.
OpenSearch. OpenSearch has no formal extension mechanism. Additional parameters can be added to a query, but their behavior is not defined. RSS and extensions can be used to encode results extensions, but all extensions would be defined in application profiles or through decisions made by individual data providers.
Google API. The Google API does not include a formally defined extension mechanism.
OAI-PMH. OAI does not include a formally defined extension mechanism.

CORDRA has no explicit requirements for an extension mechanism, but given the open nature of the problem and that the available specifications are initial versions, extensions and adaptations should be anticipated.

CORDRA Requirements Summary

The following is an overview of the CORDRA requirements and features for a query protocol and specification. It includes general features plus a summary of critical items outlined above. Since no candidate is complete, and selection will balance what features are available via the core specification and which have to be added through CORDRA profiles.

an open specification
an existing specification
not just for learning objects/content
a specification that can be profiled by a community of practice
require minimal profiling to use within a CORDRA community of practice
described with an abstract model, a service model, and a set of bindings, each differentiated and described through layers building upon the layer below
simple and lightweight (just enough features)
scalable, efficient
support multiple query languages
support multiple results format
based on a formal model for query languages and results format features
include versioning and versioning control
include an extension mechanism
support either REST or WS-* messaging
self descriptive
support discovery
operate as a stateless protocol
support caching
include flow control and QoS data
use URI-based identification
compatible with a layered authentification, authorization, identity and security models defined outside the query services

[CQL] CQL: Common Query Language, Version 1.1 (2004-02-13) SRW Editorial Board
http://www.loc.gov/z3950/agency/zing/cql/
[Google API] Google Web API, Version Beta 2 (2002-08-xx)
http://www.google.com/apis/
[OAI-PMH] The Open Archives Initiative Protocol for Metadata Harvesting, Version 2.0 (2002-06-14) Lagoze, C., et al., Eds.
http://www.openarchives.org/
[OpenSearch] OpenSearch, Version 1.0
http://opensearch.a9.com/
[SQI] SQI: Simple Query Interface Specification, Public Draft, Version 1.0 Beta (2005-04-20) Simon, B. et al., Eds.
http://www.prolearn-project.org/lori/
[SQI Sessions] SQI Authentication and Session Management Specification, Public Draft, Version 1.0 Beta (2005-04-13) Simon, B. et al., Eds.
http://www.prolearn-project.org/lori/
[SQI LORI] Learning Object Repositories Interoperability Framework, Public Draft, Version 1.0 Beta (2005-02-23) Simon, B. et al., Eds.,
http://www.prolearn-project.org/lori/
[SQI WSDL] The Common SQI WSDL Binding (CSWB)
http://sourceforge.net/projects/sqi-wsdl/
[SRW] SRW: Search/Retrieve Webservice, Version 1.1 (2004-05-20) SRW Editorial Board
http://www.loc.gov/z3950/agency/zing/srw/
[Z39.50] Information Retrieval (Z39.50) Application Service Definition and Protocol Specification, ANSI/NISO Z39.50-2003, National Information Standards Organization
http://www.loc.gov/z3950/agency/
[ZeeRex] ZeeRex: Z39.50 Explain, Explained and Reeingineered in XML http://explain.z3950.org/
[Zing] Zing: Z39.50 International: Next Generation
http://www.loc.gov/z3950/agency/zing/
[Zoom] ZOOM: The Z39.50 Object-Orientation Model
http://zoom.z3950.org/

Version	ID	Date	Change Summary
1.00	H	20050530	Initial release
		20050604	Editorial changes
		20050622	Editorial changes