 |
 |
On 18 Dec 2003 at 15:14, Mike Taylor wrote: > > 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) > yes > 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. yes, that's what I meant > > (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.) This is not what I meant and because of extraRequestData it is not needed anymore. > > 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? > I agree. In this example asking for A makes no sence, unless the server knows more about A than the client knows about B. For example when the server has full and brief records with schema B and C and extraRequestData allows the server to send full records when maximumRecords is 1 and brief records when the maximumRecords>1. Theo