> However --
> 
> > This maybe an example where ultimately SRU and SRW may have to part
> > company - i.e. where this is real need for structure in the request.
> > Arguably if the requirement is complex enough to require structure
> > in the request it is probably too complex for SRU which is intended
> > to have a low barrier of implementation.
> 
> I have problems with that idea.  Imagine someone who's built up an SRU
> client, been happily using it for several years, then wants to add the
> ability to request DC wrapped in METS.  I think it would be terribly
> hard on that person to say that they have to start over with a
> completely different protocol.

Apart from it isn't a completely different protocol -

The semantics and service definition (apart from perhaps compound record
schema support) is the same
The response is almost identical (apart from a few additional wrapper
elements in SRW)
The content of the request is the same apart from being in XML rather
than key/value pairs in the URL.

So the amount of code changes to the client would be relatively minor.

The SRU client writer already faces this - once a query becomes complex
it risks exceeding the practical limits of the length of a URL (although
there is no official limit, servers, browsers and firewalls often place
limits on the length, not least of all as extremely large URLs are a
common hackers trick in the hope of overloading buffers). In such cases,
they already need to move to either SRW or if/when introduced SRU-Post.
Likewise key/value pairs have a limit compare to richer XML structures.

SRU is lighter weight that SRW which has both advantages and
disadvantages - this particular case might not be a good one but there
will be others. For instance, what about if the SRU client writer wants
to integrate with an authentication infrastructure based on WS-Security?
Likewise, they may need to move to SRW.

Matthew