I think we should stand back a little.

Another objective was that it should be simple to implement and that we
wouldn't add things to the spec. for philosophical reasons but because
someone needed that feature in their implementation.

At the moment, I think we are beginning to veer into theory and away
from practice.

Let us for now stick with SRU and SRW. Let us also for now drop the
responseSchema element from the request (Ralph, we can put it back
latter if it turns out we really need it).

At present we don't have the response schema for SRU (the one which
includes things like the query which the browser clients will need). So
I suggest we start working on that. Once we have that we can then see
whether we really need two response schemas for SRU and SRW or whether
we could just have the one. Or (as Ralph things) one response schema for
SRU wo'n't be sufficient.

But I do feel that without this work, we are just hand waving...

Matthew

> -----Original Message-----
> From: Alan Kent [mailto:[log in to unmask]] 
> Sent: 07 February 2002 02:06
> To: [log in to unmask]
> Subject: Re: explain
> 
> 
> On Wed, Feb 06, 2002 at 10:28:06AM -0500, LeVan,Ralph wrote:
> > The "current proposal" is to stick extra information as a 
> string in a 
> > new field in the response.  The reason it isn't explainable 
> is that it 
> > is open-ended.  There is no limit to the amount of junk that can be 
> > stuck into it.
> ...
> > I don't know why I'm so offended by the idea.  Part of it is 
> > resistance to creeping featurism.  But it is exactly 
> analogous to the 
> > otherInfo that we've been using for years now.
> >
> > Keep beating at me and maybe I'll concede.
> >
> > Ralph
> 
> First, just reminding people that I am currently a fence 
> sitter on this one. I may proposed some of it, but I also 
> share Ralph's unease.
> 
> One reason I dislike it is that to me it is a bit against the 
> grain of what I see the target for SRW is. To be, SRW is to 
> provide programmers a nice easy API to Z39.50 (without them 
> even having to know its Z39.50). Dropping in a lump of XML 
> here and there for lots of different forms of extensibility 
> feels against the grain for a SOAP/RPC API. Its no longer a 
> simple API of functions.
> 
> I am wondering if instead there should be a separate protocol 
> for that. For example, we have been playing around a bit with 
> XSLT and web page formation and trying to glue it with 
> Z39.50. What looks to be really useful there is to be able to 
> give a full XML document to a server, have the server replace 
> various namespaced elements representing queries, present 
> requests, etc with the response (leaving everything else 
> alone), and then returning the page back. It allows in a 
> single HTTP POST request multiple queries, presents, etc to 
> be done. The template document sent can be based on the web 
> page layout. XSLT can then be applied to the returned page to 
> do final prettying up for display as HTML. So it addresses 
> Z39.50 encapsulation, embedded XML records, extensiblity etc 
> all in one hit.
> 
> But I think its separate to SRW and SRU (SRX?). SRX can share 
> stuff with SRW and SRU (CQL, record syntaxes maybe, etc), but 
> it would be a separate thing. So I would say:
> 
> SRU: Keep simple for GET requests with a single URL
> SRW: Keep as a very simple API for SOAP/RPC programmers to use
> SRX: Post XML data with namespaces for extensibility
> 
> Share CQL between them all. Share record syntaxes (if 
> possible) between them as well. (Share Explain?) But keep the 
> goals separate and the high level protocols separate.
> 
> Just a thought. But I understand Ralph's concerns. I think 
> the answer comes back to what the goal of SRW is. Is it to 
> make things really easy for SOAP/RPC programmers? If not, 
> what is the goal? (Ok, so I should read the web page 
> description again :-).
> 
> Alan
>