Date:Thu, 18 Dec 2003 15:14:39 GMT
Reply-To:"Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:"Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:Mike Taylor <[log in to unmask]>
Subject:Re: Betr.: Re: recordSchema
Comments:To: [log in to unmask]In-Reply-To:<[log in to unmask]> (message from Theo van Veen on Thu, 18
Dec 2003 14:15:46 +0100)
> Date: Thu, 18 Dec 2003 14:15:46 +0100
> From: Theo van Veen <[log in to unmask]>
>
> Why not the following in case the record schema is specified?
> Client requests recordSchema A,
> Server responds with one of the following:
> 1. A
> 2. Sorry I don't have A
> 3. extraRequest Data: We have B which could be used instead of A
(I assume you mean that the server responds with extraResponseData)
That's fine, so long as the client has signalled its willingness to
accept such an extraResponseData packet by sending the appropriate
"let me know what other schemas you've got if you can't do the one I
asked for" extraRequestData packet.
(Side-issue: we've always agreed up till now that
servers may not unilaterally include extraResponseData,
but only in response to an extraRequestData. Though I
would not be unwilling to revisit that rule if there
are compelling reasons to do so.)
But then we're getting dangerously close to an informally-specified,
ad-hoc, bug-ridden implementation of half of ZeeRex. Why bother? Why
not just find out what schemas are supported from the ZeeRex record
and have done?
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Oh no, Sir ... This is 'being hit on the head lessons'." --
Monty Python's Flying Circus.
--
Listen to my wife's new CD of kids' music, _Child's Play_, at
http://www.pipedreaming.org.uk/childsplay/