- From: Ray Denenberg <rden@loc.gov>
- Date: Tue, 20 Jun 2000 10:45:15 -0400
- To: ZIG List <z3950iw@lists.ufl.edu>, "ZIG List (at W3C)" <www-zig@w3.org>
Mark Hinnesbusch and I have worked up a simple DTD, in response to the suggestion at the San Antonio meeting for a distributed Z39.50 directory of servers. (Sorry, I really should have posted this a month or two ago.) Review of the discussion in San Antonio: We need a mechanism for a client to dynamically discover Z39.50 servers. We briefly considered "broadcasting" and "robots", but these ideas were passed over in favor of a simpler mechanism, a "distributed Z-directory". The approach is to define a structure that a Z39.50 server may include within the Init response -- an otherInfo item that points the client to one or more servers. The client may then initiate associations with these servers, possibly for the sole purpose of discovering more servers, and so on. The information to be supplied for each server would be: a name, IP address, port, and a URL pointing to information about the server. We decided that the "structure" will be defined in XML, not ASN.1, primarily because these directory infoItems will find their way to applications that don't directly support Z39.50 (though may communicate with applications that do). As far as I know this is the first XML structure defined for use by Z39.50, and so there are some details to be worked out. (One of the details, though relatively very minor, is the form that the ASN.1 EXTERNAL will take, which is why I initiated that thread. However, that discussion can proceed independently.) The important question -- and I think the answer is clear, but we need to get it nailed down-- is: what object identifier should be used for the syntax of this structure when it occurs in an Init Response? Clearly (it seems to me) "XML" is not sufficient (i.e. 1.2.840.10003.5.109.10), particulary for an object occuring within an Init Response, because the client will want some identifier of its semantics, so it can throw it away without opening it, if it doesn't recognize the oid. So I think the answer is to register the DTD with an object identifier, which identifies the semantics, and also implicitly identifies the syntax as XML. This is not to say that the Document Type Declaration would not also occur, redundantly, within the xml object. The draft DTD follows. Please comment on this. <!-- This DTD defines a "server list", that a Z39.50 server may include, solicited or unsolicited, within the Init response. This is intended for deployment of a distributed Z39.50 directory, allowing Z39.50 clients to dynamically discover Z39.50 servers. A server list may be included, in an otherInfo item, pointing the client to one or more servers. The client may ignore this information, or may use the information as it sees fit, for example it may initiate associations with one or more of these servers, possibly for the purpose of discovering additional servers, and so on. The information to be supplied for each server is a single Z39.50s URL (element ZURLS), zero or more URLs (type unspecified) that might provide information about the server (element URL), and a single (optional) name for the server (element Name). --> <ELEMENT Server-list (Server+)> <ELEMENT Server (ZURLS, URL*, Name?)> <ELEMENT ZURLS (#PCDATA)> <ELEMENT URL (#PCDATA)> <ELEMENT Name (#PCDATA)> -- Ray Denenberg Library of Congress rden@loc.gov 202-707-5795
Received on Tuesday, 20 June 2000 10:45:35 UTC