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