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