Note from 5/11 call

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Here is a summary of our discussion at yesterday's call.  Since the meeting was not official (no quorum) all of this is for discussion at next Monday's call.

 

 

1.  Facets.

We agree with Ralph's suggestion to remove the base URL.  Ralph also suggests that the request URL be included.   In fact it has been included, however it may not be easy to see it - it was not included in all the examples as it is optional.  So for the next draft we need to make all of this clearer, and provide more comprehensive prose description.

 

 

 

2. Search Result Analysis.

The intent is that a complex query will be broken  down into subqueries, with counts supplied for the subqueries.  Very similar to facet results. What's missing from the draft is the request URL and that will be added. Also missing is prose discussing the purpose, etc., which will be added.

 

 

 

3. Schema Parameter.

The proposal is to add a 'schema' parameter. It would be repeatable and have two parts, a type and schema identifier. 

 

Examples:    &schema=facets,info:srw/schema/1/facetResults&schema=resultAnalysis,info:srw/schema/1/resultsAnalysis

 

The standard supplies "default" schemas for facet results and result analysis. These parameters would provide a way to overide these defaults and request that these results be supplied in an alternative schema.

 

The first value would come from an extensible vocabulary that would initially include 'facets', resultAnalysis', 'records', 'diagnostics',  and 'xcql'.   The value could be a URI, and if it is not a URI it would be assumed to be part of the standard list.

 

 

4. Stylesheet parameter.

The proposal is that when the client is requesting an HTML response, and if the request supplies a stylesheet parameter, then that stylesheet parameter is meant to refer to a stylesheet on the server rather than at the client.

 

Background:

when the client supplies a stylesheet parameter, in the current protocol, it refers to a stylesheet at the client system. The client is simply asking the server to echo it back on the response.  The parameter was defined based on the assumption that the client may be so thin that it cannot even remember the stylesheet between request and response and so it want the server to remind it what stylesheet it wants to use to format the response for presentation to the user.

 

In 2.0 the client now can ask for results to be supplied in an alternative format (alternative to the default SRU response) for example ATOM or RSS, and of particular interest (for this discussion) HTML.   HTML is a special case because in contrast to ATOM, RSS or the SRU default format - each of which is defined by its own schema, if the client asks for the response in HTML it isn't specifying a particular schema, it is requesting that the server format the results for the user and return HTML that can then be directly displayed without any intervention or processing by the client.   So if HTML is requested, then it wouldn't make sense  to also include a stylesheet parameter in the request because formatting will occur at the server and the stylesheet request pertains to formatting at the client.

 

However, it would make sense, when HTML is requested, for the request to indicate how it would like the server to format the results.

 

So the idea is that when HTML is requested, the stylesheet parameter would refer to a stylesheet on the server.  When a format other than HTML is requested the stylesheet parameter would (as normal) refer to a stylesheet at the client.

 

Alternatively,  we could have separate parameters, 'localStylesheet' and 'remoteStylesheet'.   (That is, we would introduce the parameter 'remoteStylesheet', and rename 'stylesheet' to 'localStylesheet').   This approach would avoid overloading the single stylesheet parameter.  Another reason for separate parameters:  HTML may be the only format we currently contemplate would be treated in the manner described and so one might say "treat is as a remote stylesheet for HTML and a local stylesheet for everything else".  However,  we cannot rule out the possibility of some as yet  unforeseen additional format that would be treated in the same manner.