Obviously, the closer we get to interoperate the better I see the differences in underlying assumptions that were not always recognised. And I think most of them are related to using SRU and SRW. Maybe asking the following questions will help.
1) When and what for do we use SRU and when and what for do we use SRW?
2) To what extend should both SRU and SRW be interoperable?
I my case I think that SRU will mostly be used in a user oriented web-environment, where it should be easy to create dynamic links to "unknown" targets. We have a severe separation between search and retrieval of metadata on one hand and digital objects on the other hand and we will never provide binary data via SRU. We always use links to non-ascii data. I expect this will be true for most SRU users but I am not sure in that.
I think SRU can and should really be "low barrier" with the ability of browser-side processing. But that results in restrictions and we should find the right balance there. For SRW implementors the balance might be different than for SRU implementors. IMO SRU may be a subset of SRW with its limitations but with the advantage of being easy to implement by a wider range of developers.
With respect to the second question: I hope they will be interoperable, but again I wouldn't mind limitations. SRU clients quirying SRW servers and SRW clients quirying SRU servers will will work via gateways and these gateways should deal with the differences between SRU and SRW anyway.
I do not mind adding the recordPacking parameter in the URL but I also do not mind limiting SRU and SRW being identical at this point and it may even improve interoperabilty if the differences are clear and treated correctly by gateways.
These a just some thoughts.
Theo
>>> [log in to unmask] 28-11-02 00:16 >>>
> Absolutely impossible. String packing can't be "wrong".
> What happens when we want to return JPEG images as records?
> That ain't gonna happen as XML Fragments. We might introduce
> base64-encoded or something, but actually, String works just fine.
Urrm how do you pass a JPEG as a string? I think it would be a base64
encoded string or binhex string or something rather than escaped string.
That was one reason I suggested packingMethod as a parameter/response
element rather than something like XMLFragment=true|false. At present we
have XMLFragment|escapedString but in future we may have SOAPAttachment,
base64String, RDFFragment, even (dare I say it) XERFragment!
> > In the same way that it doesn't know how many records the client
> > wants, nor in what schema, yet we still allow the server to
> make this
> > decision unless instructed otherwise in the request.
>
> Yes. That too is a mistake, but not one that I propose to
> try to get changed at this stage.
Mmmmm, in the July 2001 Spec, I'm pretty sure we did default those as
well as startRecord, but those were dismissed on the basis that ZeeRex
would handle all that...
Matthew
|