OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [search-ws] Scan as a query type


I predict that we will remove the operation and version parameters and
represent them in the endpoint.   Whether you like REST or not, it just
seems to make good sense - as a practical matter: very often we are keying
in the request (or massaging it) and having to always include
"&operation=searchResponse&version=1.1" is really a pain.   I sense there is
agreement to go this route, although that may be premature, but assuming so,
then by your logic "(ii) may be syntactically equivalent to (i)" and your
preference was "ii".

I don't care for ii: "modelling as different operations (but if possible
with the same request/response formats) on the *same* database".  If they
are going to be different operations then let's declare the issue dead
(status quo).  I mean, if they are different operations why bother going to
the trouble to model an index as a database?   The purpose of doing that, I
would think, is to allow us to merge the two operations.

So your preference would be "i".  But "i" is really the same as "iv" (at
this stage, until we flesh these out), since I modified the proposal, to
separate the term records from real records into different databases, which
eliminates the concern about record format.

So it really seems to me that if we are going to raise this issue at all,
only "i"/"iv"  makes sense.

Let's either post a message to the SRU list or drop this issue.   I don't
think it's a good idea to lay out all these possibilities (just as you
convinced me not to lay out the possibilities in the ATOM posting) I really
think it all boils down to how we propose to link the indexes to the
databases.  As you suggest,  either via explain or a endpoint naming
convention.  I definitely would not want a naming convention. It should be
via explain.

Matthew, if you want to draft a message go ahead. If not I'll do it
tomorrow.

--Ray


----- Original Message ----- 
From: "Matthew J. Dovey" <m.dovey@jisc.ac.uk>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>;
<search-ws@lists.oasis-open.org>
Sent: Thursday, November 15, 2007 6:33 PM
Subject: RE: [search-ws] Scan as a query type


>  I'm assuming that we're modeling  two different databases - one for
> the
> real records and one for the terms.  So the server knows based on the
> database.

No - modelling as different databases is just *one* approach, the full
list of approaches are

i) modelling as different databases (which would mean different URL
endpoints)
ii) modelling as different operations (but if possible with the same
request/response formats) on the *same* database
iii) modelling as a single operation on a single database with a
parameter indicating whether to interpret the query as a normal search
or a scan
iv) modelling as a single operation on a single database whereby the CQL
query indicates whether this is a normal search or a scan (e.g. by using
the scan context set)

(iv) was your original suggestion of scan.index=dc.creator AND scan.term
>= <term> - I don't like this, not least of all, as the record formats
returned are now dependent on the query issued (if the query includes
the scan context set the response *must* use the scan record format)

(i) I share Ralph's concern about linking between the databases (either
via explain or a endpoint naming convention)

(iii) seems messy

So my preference is (ii)

Of course technically if we choose to continue to determine operation
via an operation parameter (ii) may be syntactically equivalent to
(iii), whereas if we move to specifying the operation as part of the URL
endpoint (ii) may be syntactically equivalent to (i) using an endpoint
naming convention!

Matthew



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]