On 10 Aug 2005 at 22:08, Mike Taylor wrote:

> > 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.
>
> Well, sure -- if someone wants a Web-Service version of the protocol
> because they want to use Web-Service stuff with it, then they need the
> Web-Service version instead of the URL version.  That is a very
> different situation from someone who just wants to make a slightly
> more elaborate requested-schema specification.
>

I agree, but what is the actual requirement?
The discussion started with only mixing rec and dc. Because the
toolkits cannot handle a simple concatenation of both containers and
need a new container (am I right?) we need a complex wrapper. So the
discussion went on with how to wrap these containers. Then this did
not fit in our requested-schema specification and we started to
invent complicated  requested-schema specifications like the
compoundRecordSchema. But these did not fit in SRU. Then we started
to discuss separating SRU and SRW because of this.
And the original requirement was to be able to tell the server: "I
want dc and you may add rec to it you have that available".

My requirement would be not to rely on the server doing the mixing
and merging according to my specifications but to look in explain if
the server has a local scheme indicating DC with servers choice
meaningful additions. I call that schema dcx with URI
info:srw/schema/3/dcx.(sorry Mike, this zombie never died)

Theo