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