RE: [search-ws] Three things

["LeVan,Ralph" <levan@oclc.org>]

Sorry to comment and run.  I'm out tomorrow and all of next week.

1) element Set Names.  The "select" clause in an SQL statement is about
specifying what sort of data should be returned.  It has nothing to do
with the query.  Drop this one.

2) .Same Container.  I have a slightly skewed view of prox from you.
I'd make "container" be the unit, and then having them in the same
container would be a distance of zero.  With that syntax, I can ask for
them in adjacent containers too.  So: A AND/proxUnit=C,distance=0 B

3) 'window 'relation.  Absolutely not.

4) Boolean modifier 'prox'.  Nope.  This example is just ugly in every
way.  Unless the relation is "exact", a quoted phrase is implicit
adjacency.  So your query is just  "fish and" not "fish and chips"

5) Structured Querying.  We don't want to go there.  Simple container
searching isn't sufficient.  They're going to want to specify a specific
instance of an element, either by offset or by a content value.  That's
what XPath is for and I'm not interested in seeing us duplicate it.

6) faceted search. Since I suggested #2, I'll vote for it.

7) query types parameter.  I strongly prefer that the query parameter
name imply the query type.  I also prefer that the query parameter name
be configurable.

8) Alternative Response Format. #1

9) Eliminate 'operation' and 'version' parameters.  Well, make them
optional in requests.

10) Allow Non-XML Record Representations.  I'm okay with the concept.
How about letting them specify a mime type in the recordPacking parm?

11) Result Set Size.  I'm okay with the concept, but I'd like to see
some specific syntax suggested.

Ralph