Date:         Thu, 31 Jan 2002 15:15:37 +1100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Alan Kent <[log in to unmask]>
Subject:      Re: Betr.: Re: ZiNG
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>; from Theo van Veen on Wed, Jan 30,
              2002 at 12:55:29PM +0100
Content-Type: text/plain; charset=us-ascii

On Wed, Jan 30, 2002 at 12:55:29PM +0100, Theo van Veen wrote:
> Considering all the discussion on responseSchema I want to give some
> additional comments:

> 1) I agree that there should be no negociation between client and
> server. The requesting message could contain a request which perhaps
> can not be fulfilled, but in that case the client should accept the
> response as it is, without negociation.

I agree with this.

> 2) There will not be "lots of" options, but that are some that can be
> foreseen (like the result of a scan or a fuzzy match). These options
> should be nillable tags in the response but the response will still
> have same responseSchema.

I think I agree with this. Scanning has not been looked at yet.
Fuzzy match may be more of a query language issue. Term highlighting
is an interesting one to me (but probably not other people).

> 3) Maybe we should drop the term "responseSchema" but instead there may
> be a need for a parameter, by  which the client can have some influence
> on which optional tags are in the response. E.g . "responseModifier" or
> something like that.

I think responseSchema should go. I think replace 'responseModifier'
with 'element set name' and we are in complete agreement.

> 4) We could define a tag sibling to <records> containing the optional
> tags. This optional tag can be processed in the same way as
> <recordData>, the syntax of which isn't defined in WDSL either.

Could you give an example of what this would be used for? I am thinking
that to keep things simple, why not just require applications to merge
such 'other' details into the record itself? Why have a second field?
A concrete example would be useful to me as to why this could not be
done.

Alan