Sure, that works if you have a smart client. But if you're using a thin
(XSLT generated) client, then there's only the user to handle the
diagnostic and they (I) get irritated after the n'th time that they
forgot to change the default position of 10 to 1.
The XSLT that generates the user interface could easily check for a
value in the Explain record that allowed it to provide an appropriate
default value.
Ralph
> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors
[mailto:[log in to unmask]]
> On Behalf Of Ray Denenberg, Library of Congress
> Sent: Thursday, April 19, 2007 3:46 PM
> To: [log in to unmask]
> Subject: Re: Explain and Scan Backwards
>
> For the less-important features our principle has been: "if you want
to
> know
> if something is supported, try it, if it isn't you'll get a
diagnostic".
> Why wouldn't that apply here? Isn't that as easy as (and less
expensive
> than) doing it the Explain way?
>
> --Ray
>
> ----- Original Message -----
> From: "LeVan,Ralph" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Wednesday, April 18, 2007 4:49 PM
> Subject: Re: Explain and Scan Backwards
>
>
> > From: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]]
> > On Behalf Of Dr R. Sanderson
> >
> >
> > On Wed, 18 Apr 2007, Mike Taylor wrote:
> >
> > > LeVan,Ralph writes:
> > > > How would I construct an Explain record to indicate that my
> database
> > > > does not support scanning backwards?
> > >
> > > You can't.
> > > (Isn't it nice to have a simple, straightforward answer for once?
> :-)
> >
> > Not to make a habit of it, but I agree with Mike :)
> >
> > Rob
>
> Doesn't this seem like a "bad" thing? I've got scan interfaces using
> default values that result in diagnostics. If there was some sort of
> indication that resultPositions greater than 1 were illegal, then I
> wouldn't see those errors.
>
> How about a hack? Got a suggestion for a benign place to stick that?
> <supports scanBackwards="false">?
>
> Ralph
|