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: Nick's comments on Feb 4 SRU document


On Nick's comments on the Feb. 4 SRU draft, I have applied to the next draft 
(not released yet) all except the following, for discussion at the next 
call.

> 329: Explicitly states that query type is restricted to query language. 
> (queryType = searchTerms is not inconsistent with that, since bare search 
> terms are a query language.) Should 317 change to rule out any other 
> categories of query?

Need to discuss this since I'm not sure exactly what language you want or 
what you mean by "categories of query".


> 509: Metasearch support: what if I don't want the separate data sources to 
> be exposed in facet search? How can I disable this behaviour?

I believe this can be addressed by adding a pseudo facet, "source",  that 
can be included in the request, but I haven't made any change along this 
line, we can discuss this next call.   So a client could discover via 
explain what the "sources" are and could actually request facets by source, 
where one of the sources is all of the sources combined, meaning "do not 
separate into distinct sources".

> 515: subquery is not defined.
The description is simply saying  "The response may provide sub query 
analysis"  where sub queries are as described below.

Not sure what the issue is here.


> 583: "If sortSchema is omitted, the server makes its best guess to 
> interpret the XPath expression": Why not just default to recordSchema as 
> the xsortSchema?

I think we've discussed this in the past and the sort experts, who have been 
Rob and Ralph,  would say that the recordSchema might offer little or no 
guidance for sorting.   Rob is no  longer with us so we'll need Ralph's 
guidance here. (Anyone else?)


> 881: This does not say explicitly whether SRU 2.0 defines Scan behaviour: 
> reader should be told where to find such behaviour defined for a /Scan 
> endpoint.
For discussion at next call.


Thanks, Nick, for the review and comments.

--Ray



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