SV: SV: [ZOOM] Multiple nonsurrogate diagnostic records?

Henrik Dahl hdahl at
Wed Jul 24 17:35:41 CEST 2002

Isn't this more a comment regarding the protocol as such and not so much
regarding a client. How do you relate your comments to this quote from the
Z39.50-1995 standard:

In " Multiple non-surrogates in Search or Present response" it
reads: "For version 3, the target may (but is not required to) include
multiple non-surrogate diagnostics in a Search or Present response and if it
does, the origin must not treat this condition as a protocol error.".

If the client can't cope with more than one diagnostic, the client
programmer can probably figure out to take the first to come and not deal
with the rest.

Best regards,

Henrik Dahl

-----Oprindelig meddelelse-----
Fra: zoom-admin at [mailto:zoom-admin at]På vegne af
Mike Taylor
Sendt: Wednesday, July 24, 2002 5:19 PM
Til: quinn at
Cc: zoom at
Emne: Re: SV: [ZOOM] Multiple nonsurrogate diagnostic records?

> Date: Wed, 24 Jul 2002 17:06:00 +0200
> From: Sebastian Hammer <quinn at>
>> Why isn't the general opinion, that the Z39.50-1995 protocol just
>> must be supported int it's entirety and that's all.

Well, wouldn't _that_ be nice?!  :-)

> My guess is that multiple surrogate diagnostics were left out of
> ZOOM at least initially to keep the API simple... it is "simple" to
> have a function that returns an error code/message which the
> programmer can then act on appropriately. By exposing multiple NSDs
> in the API you're also exposing a bit of fairly complex Z39.50
> history which, in practice, is extremely rarely used. Since one of
> the objectives of ZOOM was to lower the bar for new developers, this
> does seem reasonable.

As so often, Sebastian is right on the money.  I would want to see a
very persuasive argument for the utility of multiple NSDs before
muddying the ZOOMish waters with support for them.  Really -- who
wants their applications to get whole _arrays_ of exceptions thrown at
them?  :-)

> It's probably reasonable to consider whether ZOOM should expose
> multiple NSD's -- perhaps through a different API call (the simple
> call could be restricted to return only the *first* NSD, since this
> is frequently all a simple-minded application needs to know it's in
> deep water and shut down).

Yes indeed.  I honestly struggle to think of _anything_ else that
client code could do with multiple NSDs apart from showing them to the
human user.  Which sort of dirty-laundry exhibition is generally
frowned on anyway.

> This approach appeals to me because it preserves the simplicity (and
> backwards compatibility) of the interface, while still allowing
> those who need it access to the entire protocol.

I still prefer not to have ZOOM address multiple NSDs _at all_,
because even if the support is optional (== never used), the sheer
additional verbiage in the AAPI will make it more offputting to
readers.  For me, Lesson Number One that we should learn from Z39.50's
failure to take off is that an intimidating document is an unread
document.  I think that the AAPI's current size of 5200 words is
already skimming the edge of the unacceptable, and I'm pretty much
planning to rip out Appendix A (Motivation) in v1.3 for that reason.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at>
)_v__/\  "Taking reservations for eternity: Smoking or Non-smoking"
	 -- Church Sign Board.

ZOOM mailing list

More information about the ZOOM mailing list