[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] RE: sru/cql sort
> There MUST be a query, and that query identifies or describes a result > set. Sort, as specified in CQL, is a part of that description as it > affects the ordering, in exactly the same way as relevance ranking does > for example. Sure, it affects the ordering, but not the creation of the result set. It's just as legitimate to do the sorting after the result set creation as during; it's just not as convenient. > It makes it more complex to have two parameters, both of which contain > CQL, one of which is mandatory, than to retain the status quo of one > mandatory parameter that can optionally have a sort specification > included in it. By that logic, we should roll Scan into search, because it has a CQL clause. It's not a good argument for integrating search and sort. > If CQL retains its ability to map prefixes, you would have to do the > mapping twice, once in each parameter. Well, I doubt humans are manually typing in CQL prefix mappings, and I don't care about the redundancy for machine apps. > If CQL is to be used outside of SRU, and it already IS being used > outside of SRU in Jangle for example, then it makes sense to have its > own sort specification rather than requiring every other project to > reinvent it. If SRU 2.0 doesn't want to use it, then it can split it > off into a second parameter, but the language should retain the > ability. I'm okay with that. > It also closely follows SQL, which most implementations will use > underneath anyway, and is familiar to developers. Sorry, but that is a bogus argument. If we were to follow that logic, we'd dump all our record selection parms in favor of a SELECT clause in the query. Ralph
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]