I'm not talking about sending anything and wasting bandwidth. There are extensions that are useful to all users and extensions that are only useful for specific situations. The server knows that better than the client. I would consider a client that breaks down on unsollicited extra data not well implemented. As a user I would prefer a client that allows me to see the unsollicted extra data. But my client wouldn't say to the server that it accepts anything because the client can not judge the usefulness for the user. The server can.
From: SRU (Search and Retrieve Via URL) Implementors on behalf of Dr R. Sanderson
Sent: Sat 3/29/2008 12:23 PM
To: [log in to unmask]
Subject: Re: Price information in SRU responses
> 2) we may rely on system engineers to deal with unsollicited in a
>responsible way. Many servers have extensions that might be useful for
>others. Only extensions that are not useful for others should be on
This is my main problem with the proposal.
1. Surely if an extension is not useful, it wouldn't exist?
2. Assuming that there are non-useful extensions, how do you determine
if an extension is or is not useful to the current client?
3. Assuming that you have a well implemented server, you could return
an AWFUL lot of extra data about a record, the search, the terms in
scan, etc. You're just wasting everyone's bandwidth and processing time
by sending unwanted data that the client probably doesn't know what to
do with. Yes you can safely ignore it, but that is not a zero cost
4. If, as a client, you want to get back anything, we have a way to do
it -- the accept extension. I don't see why this should be forced on to
everyone when clients that want it can easily have it. Just put it at
the beginning along with the static operation and version parameters and
forget about it. :)
5. For some clients, getting back unknown elements could break them if
they use very strict XML processing rules. Enforcing something that is
known to break otherwise well implemented clients is not good behaviour!