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