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)


> 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.