SV: SV: SV: [ZOOM] Multiple nonsurrogate diagnostic records?
hdahl at inet.uni2.dk
Fri Jul 26 16:53:07 CEST 2002
Yes of course. If we take the strict mathematical approach and talk about
computability, it's obvious that the cause for MNSD has to be multi
Fra: zoom-admin at indexdata.dk [mailto:zoom-admin at indexdata.dk]På vegne af
Sendt: Thursday, July 25, 2002 11:42 AM
Til: hdahl at inet.uni2.dk
Cc: zoom at indexdata.dk
Emne: Re: SV: SV: [ZOOM] Multiple nonsurrogate diagnostic records?
> Date: Wed, 24 Jul 2002 20:42:15 +0200
> From: "Henrik Dahl" <hdahl at inet.uni2.dk>
> I would like to give a concrete example of a potential use of
> MNSD. [...] If the server does not implement the domestic attribute
> set but on the other hand responds conveniently it should now issue
> two NSD records, one stating that it does not support the one
> attribute and another stating that it does not support the other
> one. The clever client could now fall back on the generic BIB-1
> attribute, letting the user to suffer from a more broad search, but
> not to suffer so much that he would just get an error. The even more
> clever client could inform the user on this action taken.
Thanks Henrik. All that you say is true, but the same kind of
fallback behaviour is just as possible if only single NSDs are
returned -- the client will simply have to make two failed searches to
discover that the two attributes are unsupported.
Here is what, for me, is the clincher: the client will have to include
code for the multi-stage fallback, because there are so many
one-NSD-at-a-time servers out there. So why bother making it also
understand the single NSD? I just don't see that it buys anything.
/o ) \/ Mike Taylor <mike at miketaylor.org.uk> www.miketaylor.org.uk
)_v__/\ "I love English: in what other language can you make things
so obscure by explaining them?" -- Zenlizard.
ZOOM mailing list
ZOOM at indexdata.dk
More information about the ZOOM