Foreword The primary author of these notes is Eliot Christian , with contributions also from Ralph LeVan , Sebastian Hammer , and Ray Denenberg . Positions expressed here have yet to be coordinated with the DASL and GILS communities generally. -------------------------------------------------------------------------------- References These notes are related to the suggested alignment of DASL and GILS. "GILS" here refers to version 2 or subsequent versions of the GILS Profile for information search (version 3 of GILS is expected to be issued in 2000.) "DASL" refers to an IETF working group and its proposed search protocol for WebDAV . A DASL/ GILS Terminology Cross Reference is available at -------------------------------------------------------------------------------- Alignment of scope The DASL proposal specifies a search protocol operating within the Internet operating environment using existing TCP/IP, HTTP, and XML specifications (plus some extensions). This comparison assumes the specification of XML Encoding Rules (XER) . When approved as part of ASN.1 (Abstract Syntax Notation), XER will standardize a representation of the ISO 23950 (ANSI Z39.50) search protocol using existing TCP/IP, HTTP, and XML specifications. Aspects of GILS other than its realization as a search protocol on the Internet (e.g., policies and usage guidelines, metadata element semantics) are not addressed here. -------------------------------------------------------------------------------- Notes on DASL/GILS alignment A set of notes pertaining to discussions during the DASL/GILS Alignment Workshop is available at The following notes prepared prior to the Workshop are keyed to paragraphs in the DASL INTERNET-DRAFT dated November 18, 1998. These notes focus primarily on the aspects of DASL that were stated as "MUST" be supported. >1.2. Relationship to DAV > > DASL relies on the resource and property model defined by > [WebDAV]. DASL does not alter this model. Instead, DASL allows > clients to access DAV-modeled resources through server-side > search. NOTES: Search support for the model defined by WebDAV is straightforward for a GILS-compliant server. Each WebDAV property is mapped to a Use Attribute. Those that correspond with existing Bib-1/GILS semantics ("well-known Use attributes") are handled by their registered number. Because they are well-known in Bib-1, these will have extensive search interoperability with virtually all implementations supporting Z39.50. Search on other WebDAV properties would be handled in GILS by their USASCII string tag names (such Use Attributes are known to GILS as "locally-defined"). Retrieval support for WebDAV properties is also straightforward if one models XML objects with WebDAV properties as a set of records comprising a Z39.50 "database". Each WebDAV property is then regarded as a record element, and the retrieval machinery of Z39.50 is available to retrieve individual elements (properties) or the full set of elements ("allprop"). Of course, a result set can also consist of URI references ("href") if the retrieval machinery of HTTP is to be used instead. >1.5. An Overview of DASL at Work > > One can express the basic usage of DASL in the following steps: > > - The client constructs a query using the DAV:basicsearch grammar. > > - The client invokes the SEARCH method on a resource that will > perform the search (the search arbiter) and includes a text/xml > request entity that contains the query. > > - The search arbiter performs the query. > > - The search arbiter sends the results of the query back to the > client in the response. The server MUST send a text/xml entity > that matches the [WebDAV] PROPFIND response. NOTES: This usage has good equivalence to Z39.50/GILS. - The client constructs a query using the Z39.50 equivalent to DAV:basicsearch, i.e., structures specified in the Z39.50 ASN.1 for a searchRequest and encoded for transmission using XER. - The Z39.50 equivalent to invoking a search method is that the client sends the searchRequest (a "text/xml request entity") to a Z39.50 target, i.e, an Internet server process acting as search arbiter. - The server process constructs a searchResponse using XER (also a "text/xml entity") and sends this structure to the client. A Z39.50 retrieval schema can be used to select elements and align the response structure with PROPFIND. >2. THE SEARCH METHOD > >2.1. Overview > > The client invokes the SEARCH method to initiate a server-side > search. The body of the request defines the query. The server > MUST emit text/xml entity matching the [WebDAV] PROPFIND > response. NOTES: Although the text/XML syntax is not specifically required to be supported by a version 2 GILS-compliant server, popular implementations already do or soon will support XML. It can be expected that server support for XML syntax will be required in GILS version 3. > The SEARCH method plays the role of transport mechanism for the > query and the result set. It does not define the semantics of > the query. The type of the query defines the semantics. > NOTES: This is equivalent to Z39.50/GILS. The client can be said to have initiated the search when the searchRequest is received by the server. The body of the searchRequest includes the Query Type, which defines the semantics. >2.2. The Request > > The client invokes the SEARCH method on the resource named by the > Request-URI. > >2.2.1. The Request-URI > > The Request-URI identifies the search arbiter. NOTES: The registered "z3950s" URI identifies the search arbiter as a server process on a host at a port. The z3950s URI may optionally specify other parameters such as "database-name". > The SEARCH method per se defines no relationship between the > arbiter and the scope of the search, rather the particular query > grammar used in the query defines the relationship. For example, > the FOO query grammar may force the request-URI to correspond > exactly to the search scope. NOTES: Z39.50 has a similar distinction that allows for alternate query types, which seem analogous to DASL query grammars. I am not sure whether SCAN and SORT might also be regarded as query grammars from the DASL perspective. >2.2.2. The Request Body > > The server MUST process a text/xml request body, and MAY process > request bodies in other formats. > > If the client sends a text/xml body, it MUST include the > DAV:searchrequest XML element. The DAV:searchrequest XML element > identifies the query grammar, defines the criteria, the result > record, and any other details needed to perform the search. NOTES: Existing z39.50 servers provide services using ASN.1/Basic Encoding Rules, equivalent to the XML generated through XML Encoding Rules. A valid client searchRequest can only be constructed according to the ASN.1 specification with appropriate encoding rules. That searchRequest identifies the query type ("query grammar"), defines the query ("criteria"), the result set, and other details needed to perform the search. >2.3. The DAV:searchrequest XML Element > > > > > The DAV:searchrequest XML element contains a single XML element > that defines the query. The name of the query element defines > the type of the query. The value of that element defines the > query itself. NOTES: This is parallel to Z39.50/XER. A searchRequest XML element defines the query with a "query" element. The type of query is named by the a query type subelement, e.g., "type-1". The value of that element defines the query itself. Here is an example: bib-1 [ rpn element structure not shown ] >2.4. The Successful 207 (Multistatus) Response > > If the server returns 207 (Multistatus), then the search > proceeded successfully and the response MUST match that of a > PROPFIND. > > There MUST be one DAV:response for each resource that matched the > search criteria. For each such response, the DAV:href element > contains the URI of the resource, and the response MUST include a > DAV:propstat element. NOTES: In a typical GILS implementation, there would be a result set containing a record for each resource that matched the search criteria. These can be returned immediately ("piggy-backed") with a searchResponse or retrieved separately with a presentRequest and presentResponse. (A resultSetName is returned so that the client can request records from the result set.) An "href" and a "propstat" element could be populated by a DASL-aware, GILS- compliant server. >2.5. Unsuccessful Responses > > If an error occurred that prevented execution of the query, the > server MUST indicate the failure with the appropriate status code > > and SHOULD include a DAV:multistatus element to point out errors > associated with scopes. > > 400 Bad Request. The query could not be executed. The request may > be malformed (not valid XML for example). Additionally, this can > be used for invalid scopes and search redirections. > > 422 Unprocessable entity. The query could not be executed. If a > text/xml request entity was provided, then it may have been valid > (well-formed) but may have contained an unsupported or > unimplemented query operator. > > 507 (Insufficient Storage). The query produced more results > than the server was willing to transmit. Partial results have > been transmitted. The server MUST send a body that matches that > for 207, except that there MAY exist resources that matched the > search criteria for which no corresponding DAV:response exists in > the reply. NOTES: Z39.50 provides a well-developed and extensible diagnostic capability, with a rich set of existing diagnostics. Communicating such diagnostics via HTTP is typically handled by an HTTP/Z39.50 gateway rather than mapping query diagnostics onto HTTP itself. In a Z39.50/XER implementation over HTTP, this DASL approach might well be preferred. >3.1. The OPTIONS Method > > The OPTIONS method allows the client to discover if a resource > supports the SEARCH method and to determine the list of search > grammars supported for that resource. > > The client issues the OPTIONS method against a resource named by > the Request-URI. This is a normal invocation of OPTIONS defined > in [RFC2068]. > > If a resource supports the SEARCH method, then the server MUST > list SEARCH in the OPTIONS response as defined by [RFC2068]. > > DASL servers MUST include the DASL header in the OPTIONS > response. This header identifies the search grammars supported by > that resource. >[...] >4. QUERY SCHEMA DISCOVERY: QSD > > Servers MAY support the discovery of the schema for a query > grammar. > > The DASL response header provides means for clients to discover > the set of query grammars supported by a resource. This alone is > not sufficient information for a client to generate a query. For > example, the DAV:basicsearch grammar defines a set of queries > consisting of a set of operators applied to a set of properties > and values, but the grammar itself does not specify which > properties may be used in the query. QSD for the > DAV:basicsearch grammar allows a client to discover the set of > properties that are searchable, selectable, and sortable. NOTES: The Z39.50 init service provides a means to communicate certain options, though not the full set required in DASL. Information about options could be obtained from an Z39.50 Explain service. However, few such Explain databases exist in operational implementations. In common practice, a Z39.50 client can discover what options a server supports by simply trying it. On a search using the "Bib-1" attribute set, a diagnostic of "Unsupported Attribute Set" indicates very circumscribed server functionality. Given that there are many hundreds of Use attributes, this error diagnostic approach is obviously inferior to wide deployment of the Explain service if one needs to discover whether particular attributes are supported. Sets of supported Z39.50 options are specified through the several Z39.50 Profiles. Of particular interest is a set of four nested Z39.50 Profiles: WAIS, GILS, GEO, and CIP. (The Geospatial Profile is particular to metadata about data and information referenced to places on Earth; the Catalog Interoperability Profile is particular to dissemination of remote sensing databases.) Each of these in order is a functional superset of the others. A mechanism to negotiate supported profiles of Z39.50 was recently specified in the standard, though it is not yet broadly implemented. >5. THE DAV:BASICSEARCH GRAMMAR > >5.1. Introduction > > DAV:basicsearch uses an extensible XML syntax that allows clients > to express search requests that are generally useful for WebDAV > scenarios. DASL-extended servers MUST accept this grammar, and > MAY accept others grammars. > > DAV:basicsearch has several major components: DAV:select, > DAV:from, DAV:where, DAV:orderby, and DAV:limit. DAV:select > provides the result record definition. DAV:from defines the > scope. DAV:where defines the criteria. DAV:orderby defines the > sort order of the result set. DAV:limit provides constraints on > the query as a whole. NOTES: 'select' seems to be analogous to the Z39.50 concept of a presentation schema applied to an instantiated result set. 'From' seems analogous to the Z39.50 database parameter, 'where' is analogous to the Z39.50 query. 'Orderby' is analogous to "sort" in Z39.50. However, in Z39.50, the sorting operation occurs on a result set. There has been discussion of allowing a sort to be concatenated with a search, but there is no standard for that at present.