RE: [search-ws] SWS description document

["Janifer Gatenby" <Janifer.Gatenby@oclc.org>]

I think that we also need:

o) How to browse
A description will enable your client to discover the indexes (access
points) that can be browsed, how to construct a browse and browse
options and their defaults.  Example browse URLs may be included.

Also under "How to search" I think that we shoudl add "Example search
URLs may be included".

I think that the examples are one of the strengths of the OpenSearch
description document.

Janifer



-----Original Message-----
From: Ashley Sanders [mailto:a.sanders@manchester.ac.uk] 
Sent: 03 October 2008 15:32
To: search-ws@lists.oasis-open.org
Subject: Re: [search-ws] SWS description document

Janifer wrote:
> Dear Colleagues,
>  
> As promised, here is a document that attempts to scope the SWS 
> description language and SWS description documnet.

I thought Janifer's document went into too fine a detail on some points,
so here's my version of Janifer's document....

-------------------------------------------------------------------
Search Web Services:  Description Language

[In the following, by "client" I mean a piece of software that reads in
a "Description" and interacts with the web based service that is being
described by the "Description".]

The purpose of the description language is to act as a standard way to
produce a document that allows sufficient information for a third party
client to access, query and process results from a web based database or
query service.

The description language describes a server's capability in respect of:

o) How to submit a search.

If the service is form based, then the Description will tell your client
how to populate the form fields. If the service uses a query language,
such as CQL, then a Description will enable your client to construct an
appropriate query.

o) How to parse the results of the search.

A Description will enable your client to extract from the server's
response the information it needs to perform the task in hand. Ie, it
will be able to extract from the response the result records, number of
records found, diagnostics, sort order, etc, etc.
In fact any item of information contained in the response should be
extractable by the client for use in either further service requests or
any other task the client has to perform.

o) How to further interact with the server.

If extra operations are needed to, say, sort a result set or retrieve
further records from a result set, then a Description will enable your
client to construct the correct url to perform that operation and then
analyse the result from the server.

o) How to handle cookies.

A Description will tell a client which cookies it needs to store and
return to the server and what their default value need be.

The description document may be made by the provider of a database or
query service or it may be made by a third party. The ability of third
parties to make description documents means that any database available
on the web has the potential to be accessed via this standard without
requiring any changes to the way in which the database enquiry behaves.
-------------------------------------------------------------------

Sorry this has taken me so long, but I've been rather busy of late.
I'll also be away for the next fortnight.

Regards,

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php