Date:         Thu, 20 Jun 2002 16:37:43 -0400
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "LeVan,Ralph" <[log in to unmask]>
Subject:      Re: resultSetId parameter in request
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

Correct.

Ralph

> -----Original Message-----
> From: Ray Denenberg [mailto:[log in to unmask]]
> Sent: Thursday, June 20, 2002 4:01 PM
> To: [log in to unmask]
> Subject: resultSetId parameter in request
>
>
> "LeVan,Ralph" wrote:
>
> > I disagree with Ray's claim about case #2.  But, I do
> consider putting the
> > resultSetID as the only entry in the query to be a hack to
> eliminate a
> > parameter.  If anyone else thought that just adding a
> resultSetID to the
> > request was a good idea, then I think we should seriously
> consider it.
>
> I doubt anyone will object -- the reason there isn't an
> explicit parameter no
> longer applies. I'll add it to the service definition and if
> someone doesn't
> want it they'll need to speak up.
>
> But we need to be sure we agree how  this parameter is to be
> used: If it's
> supplied, then the query string shouldn't be supplied. I.e.
> it is explicitly a
> request for records from an existing result set, not a
> request to execute a
> query. Right?   (And it's not an attempt to name the result
> set. It has to be
> a result set id that has been previously supplied by the server.)
>
> --Ray
>