Date:         Tue, 11 Jun 2002 17:23:18 +0200
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      Betr.: Re: SRW Statuses
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII

For me it is not clear whether the status is to be interpreted by the client or is relevant to the user. In the latter case a partial succes status, indicating that the result does not "exactly" represent what the user requested, might help. I do not think there needs to be separate statuses for search, present and resutset, but a distinction between statuses indicating system failures or diagnostics that are relevant to the user would be helpful.

Theo  


>>> [log in to unmask] 11-06-02 16:38 >>>
I agree too.  I don't really like partial success and don't see it is needed
if there are surrogate diagnostics.  Success should mean that the search was
successfully performed even if the result count is zero.

I would also like to see sort as an option within CQL, not a separate
service.

Janifer

-----Original Message-----
From: LeVan,Ralph [mailto:[log in to unmask]] 
Sent: Tuesday, 11 June 2002 15:59
To: [log in to unmask] 
Subject: Re: SRW Statuses


I've got no problem with that.

Ralph

> -----Original Message-----
> From: Matthew Dovey [mailto:[log in to unmask]] 
> Sent: Tuesday, June 11, 2002 5:35 AM
>
> But my view here is that we can simplify this by having a
> success/failed
> status and indicating the reason (search failed, present failed - or
> something a little more meaningful for those not steeped in
> Z39.50 - or
> whatever). I'm not sure either way about the need for the partial
> success value.
>
>
>
> Matthew
>
>
> > -----Original Message-----
> > From: LeVan,Ralph [mailto:[log in to unmask]] 
> > Sent: 10 June 2002 23:51
> > To: [log in to unmask] 
> > Subject: Re: SRW Statuses
> >
> >
> > I like the idea of the three statuses: search, result set and
> > present.  In fact, the result set info could be in the
> > statuses part of the response.
> >
> > I also like surrogate diagnostics.  There are many reasons
> > why a record can't be returned and often the client/user does
> > care what that reason was.
> >
> > Ralph
> >
> > -----Original Message-----
> > From: Ray Denenberg [mailto:[log in to unmask]] 
> > Sent: Monday, June 10, 2002 5:19 PM
> > To: [log in to unmask] 
> > Subject: SRW Statuses
> >
> >
> > Just looking at the response schema at
> > http://www.loc.gov/z3950/agency/zing/rs1.xml 
> > and must admit I
> > haven't looked at it closely for
> > awhile.
> >
> > I think the status part needs work.
> >
> > First: there is a single status, whose values are
> > : "0 - success 1 - partial success (some surrogate
> > diagnostics present in records structure) 2 -
> > failure"; similar to the Z39.50 present status.
> > There's no search status or result set status.
> > Remember that the srw service  (loosely) models
> > the Z39.50 Search with piggyback response.  That
> > has a search status, result set status, and
> > present status.
> >
> > Second: couldn't we dispose of the surrogate
> > diagnostic for srw?  How about an element that
> > accompanies a record, telling which result set
> > record it is. Then if you get records 1, 3,4,5 you
> > know that 2 couldn't be returned, for some reason.
> > Do we need to bother with the reason? And that's
> > only for a persistent result set anyway;  much of
> > the time the queries are going to be re-executed
> > in which case the surrogate diagnostic isn't very
> > meaningful.
> >
> > Could we do away with the status(es) altogether,
> > and just send diagnostics?
> >
> > --Ray
> >
>