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