First stab at profiling a server

[Ashley Sanders <a.sanders@manchester.ac.uk>]

Hi,

 > For example, a server operating under the SRU1.2 profile would supply 
 > an SRU1.2 response.  On the other hand, a server might supply a
 > response according to no named schema, but will describe how
 > parameters values are to be extracted from a response.  A server
 > might respond with XML, or HTML, etc.  For XML, it might supply
 > as part of its description an Xpath expression to use to extract
 > a specific parameter. For HTML, it might supply a regular expression.
 > Ralph and Rob (and maybe Ashley) will supply several examples, which
 > will be integrated into the next version of the Core Spec.

Some quick notes pretty much off the top of my head as to how I'd
see SWS profiling a service. I'll apologise in advance for doing
this in XML, as I'm guessing XML is pretty much expected nowadays.

1. Some examples of how I might specify how to find the number
of records found in the response:

<!-- Where the number of records is found in, say, an HTML
  element with a ID of numRecs. -->
<sws:numberOfRecords>
  <sws:id id="numRecs"/>
</sws:umberOfRecords>

<!-- Where the number of records is found with a XPath. -->
<sws:numberOfRecords>
  <sws:xpath path="/za:searchRetrieveResponse/zs:numberOfRecords"/>
</sws:umberOfRecords>

<!-- Where the number of records is found via a CSS type
   specification. -->
<sws:numberOfRecords>
  <sws:select select="body p span.num_recs"/>
</sws:umberOfRecords>

<!-- Where the number of records is found between two strings. -->
<sws:numberOfRecords>
  <sws:bounded begin="Number of hits: " end="."/>
</sws:umberOfRecords>

<!-- Where the number of records is found with a regexp. -->
<sws:numberOfRecords>
  <sws:regexp regexp="Number of hits: ([0-9]+)" use-sub-match="1"/>
</sws:umberOfRecords>

2. Constructing a query. Here are a few ways that I can envisage
describing how to construct the part of the url that forms the query.

<!-- The server accepts an SRU 1.2 cql query string,
  where the url parameter name is "query" and boolean AND and OR
  are supported, but boolean NOT is not supported. -->
<sws:query>
  <sws:cql param="query" version="sru1.2">
   <sws:boolean and="yes" or="yes" not="no"/>
   <!-- Other stuff here about which relations are supported,
    context sets, etc, etc. -->
  </sws:cql>
</sws:query>

<!-- The server is HTML form driven. This example describes
  the Copac quick saerch form. -->
<sws:query>
  <sws:form>
   <sws:field name="au">            <!-- General author field. -->
    <sws:author type="normalized"/> <!-- Normalize names if possible. -->
   </sws:field>
   <sws:field name="ti"/>           <!-- Title field. -->
    <sws:title/>
   </sws:field>
   <sws:field name="any"/>          <!-- General keyword field. -->
  </sws:form>
</sws:query>

<!-- A Google style single field query. -->
<sws:query>
  <sws:field name="q">
   <sws:boolean-and/> <!-- Boolean AND is the default. -->
   <sws:boolean-or infix=" OR "/>
   <sws:boolean-not prefix="-"/>
   <sws:phrase quote="&quot;"/>
  </sws:field>
</sws:query>

3. In describing the Copac quick search form, the elements
sws:author and sws:title are meant to have some semantics
behind them. I would envisage defining a set of such elements
with their semantics -- something that looks like (dare I say
it) a set of z39.50 Use attributes or something that maps
to Dublin Core type classifications.

I think that's all I have time for right now. I'll try and
read the email over the Christmas break, but I'm not back in
the office until the 2nd Jan.

Merry Christmas and a happy New Year to all.

Ashley.
-- 
Ashley Sanders               a.sanders@manchester.ac.uk
Copac http://copac.ac.uk A Mimas service funded by JISC