> Envelope-to: [log in to unmask]
> Delivery-date: Thu, 07 Aug 2003 15:24:13 +0200
> Content-Type: text/plain; charset=US-ASCII
> Content-Disposition: inline
> Date: Thu, 7 Aug 2003 15:17:15 +0200
> Reply-To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
> Sender: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
> From: Theo van Veen <[log in to unmask]>
> Comments: To: [log in to unmask]
> X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20
> X-Spam-Level:
> I don't think that I ask for unlimited creativity of the server but
> merely to specify alternative responses that are more useful than an
> error message. Clients and servers need to become creative when we
> do not do that.

This is precisely what we cannot, IMHO, allow.  I will agree with you
that SRW/U might well profit from a richer diagnostic structure -- but
that is all.  The word "creative" looks nice and appealing sitting
there innocently like butter wouldn't melt in its mouth, but we all
need to remember that in this discussion, "creative" has the meaning
"sloppy, unpredictacle, non-interoperable".

And, by the way, the lesson of Z39.50 (the BIB-1 diagnostic set
vs. the Diag-1 diagnostic format) is surely that implementors want
_simpler_ diagnostics even when they are plainly inadequate.  So I am
actually not even convinced that rich diagnostics in SRW are a good
idea.  We already have one capability discovery mechanism (ZeeRex),
why add another redundant one?

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>
)_v__/\  "Take this bus to Cuba!" -- Monty Python's Flying Circus.

Listen to my wife's new CD of kids' music, _Child's Play_, at