I am a little bit concerned about the responseSchema. My dream (and I hope we had the same dream) was that we could come to some standard protocol that would work always and for every SRW-target and SRW-client. Having different resonseSchemas should definitely not introduce interoperability problems. When I introduce a responseSchema to do things my own way, than that declines from the standard than that is not what I want.
Of course we will have some local extras and others will probably others will also have their local extras. But a minimum requirement should be that our clients (just html-pages and stylesheets) are capable of doing basic searching in all SRW-targets and the all other clients should be capable of searching in our databases. When I introduce a new responseSchema to make life easier for me, than that does not make sense if that responseSchema doesn't work for other targets.
So I try to conform to the standard and try to find my way around some problems. But we have to avoid the need for extra responseSchemas. I think that accepting the following will help improving the standard in this respect and will make it more dynamic without adding complexity and without the need for introducing extra responseSchemas.
1) Allowing clients without state (browsers do not keep state between pages) by returning the original url parameters as xml-tags in the response.
2) Allowing for url-parmeters that are not defined in the standard. If desired, some of these parameters can always become part of the standard.
3) Allowing for extra (even unsollicited) responses sibling to searchRetrieveresponse rather than instead of searchRetrieveresponse. E.g. it would improve the overall quality of a search and retrieve protocol if "no hits" would automatically lead to a list (in xml) with best matching entries). If the stylesheet or client can handle this response it's fine, when it cannot, it won't harm.
Theo
>>> [log in to unmask] 20-11-01 16:03 >>>
> -----Original Message-----
> From: Theo van Veen [mailto:[log in to unmask]]
>
> First lets keep SRW simple and make sure that the
> implementation barrier is low so that implementation becomes
> possible for a large group of people. It should for regular
> metadata like (title, author etc.) always be possible to
> create XML output without the need for SOAP and which can be
> presented on the client with just an XSL-stylesheet.
> Extensibility and interoperability are in many cases a matter
> of simplicity. So forget about new mime-types and lets stick to XML.
There need be no relationship between SOAP and the generation of XML. My
server is making the XML on the fly and returning it in a SOAP wrapper in
response to a SOAP request.
> Interoperability is also a matter of being strict in
> agreements that do not interfere with functionality (like
> agreeing on the use of prefixes, recordnumbers, fixed record
> schemas, query syntax etc.)
Prefixes are not something that can be controlled. They are often generated
automatically by the XML tools. Besides, they don't really exist. If you
replace the prefix with the actual URI that they represent, then your
version of the XML tag and my version should be identical.
I agree that we need to agree on some record schemas. We've loosely agreed
on DC and ONIX as those schemas, but that agreement needs a little rigor.
We will need to eventually agree on the details of the query syntax, but I
am happy to let that one evolve with some implementor experience.
Adding record numbers to the base agreement is a step away from simplicity.
It assumes a client with no state. If we accept that assumption then we'll
need to add a lot of other things besides record number. While I'm
sympathetic to those requirements, I don't want them in the base standard.
They are exactly why responseSchema is a parameter in the request.
> And interoperability is also a matter of tolerance with
> respect to those aspects that have to do with extensible
> functionality (like allowing extra url-fields in the request
> and extra xml tags or xml response blocks in the response
> without being predefined).
Sorry, but I don't understand either of these two issues.
> We want to make SRW the main extrance to our OPAC and other
> databases as soon as possible but at the same time we want to
> conform to a standard. I want to mention here the things for
> which our current implementation declines from the current
> standard and that I would like to become part of the standard
> or have alternatives suggested to me.
>
> 1) We use recordnumbers in the xml-output to allow browsing
> without the need for keeping session context
Specify your own responseSchema that contains that information.
> 2) We allow the stylesheet-url being put in the request
> (xsl=http:// ...), so that the SRW-server can put this in the
> XML-header, so that it can be used by Internet Explorer automatically.
Clever idea. But, it would require an additional parameter in the request
and I'm disinclined to add that complexity to work around a temporary IE
problem. The real fix is the ability to specify to IE a table that maps
record schemas to stylesheets.
> 3) We allow three three record schemas: kb_caption, kb_record
> and dc. The first to are for internal use only, for dublin
> core I want to suggest dc_record (full record) and dc_caption
> (brief presentation) as being minimal requiered for
> interoperability purposes.
My implementor experience is that I always ask for the full record, even for
brief displays, because my definition of the necessary fields in a brief
display rarely corresponds to the definition used by the server.
> 4) We return unknown url-fields as xml-tags that can be used
> by external applications to keep session context.
Sorry, but I don't understand this one.
> 5) We have the field zng:recordid in the xml and recordid as
> url parameter to allow for requesting records by means of
> some identifier outside the scope of a resultset.
Gosh, we've never done that in regular Z39.50, so I don't want to do that
here. A strict rule for use must be semantic interoperability with Z39.50.
In the case of SRW, I don't even see the need for this, since all record
requests can be accompanied with a query.
> 6) We do not yet use the parameter responsschema. Is
> searchRetrieveResponse one of the responsschemas or will
> different responsschemas be part of the searchRetrieveResponse.
As I've been discussing with Alan and Matthew, we've got a conflict in
requirements. A strict SOAP RPC interpretation would say that
responseSchema is meaningless, because responses are not defined by a
schema. They are defined as an object specified in the WSDL.
For responseSchema to be meaningful, then the response to a request needs to
be an XML record whose contents can vary, depending on the responseSchema.
That is not what we currently have defined in our WSDL, but that is what I'm
returning out of my server.
I've suggested that we need to support both mechanisms and I'm waiting for
responses.
> 7) We use zng: and dc: prefixes. I do not know how to specify
> in xsl or xslt a current namespace. I want to suggest agree
> on using prefixes.
Sorry, but we can't do that, for the reasons I gave above.
If by "current namespace", you mean default namespace, then maybe I can help
with that problem. This article explained everything I needed to make XSLT
work for me with default namespaces.
http://www.topxml.com/people/bosley/defaultns.asp. (I'm using XSLT to make
the DC records in my responses and I spent a half day beating my head
against the default namespace problem before I found this article.)
> 8) Within a query I use field:term (e.g. author:smith), but
> is there already agreement on using some character to
> separate field and terms?
That's part of the stuff to be agreed on. In my original CQL proposal, I'd
suggested some additional characters but I have since reconsidered that
decision. For right now, I think the colon is the correct character to use.
> As I have said before in important use of SRW will be in
> local applications with just a stylesheet for presentation in
> Internet Explorer. I would be disappointed when SRW could not
> be used for that kind of application and this only requires
> XML responses to be selfcontaining (which alos increases robustness)
As I've said before, I'm sympathetic to this requirement and will try to get
it into our agreements. But my highest priority is to simplicity in the
protocol.
Ralph
|