[This is resend 2 of 3]
--
Date: Thu Apr 7 13:47:09 +0100 2005
From: Mike Taylor <[log in to unmask]>
> Date: Thu, 7 Apr 2005 12:49:55 +0100
> From: Dr Robert Sanderson <[log in to unmask]>
>
> To summarise, so that I'm sure I understand the discussion:
>
> * Servers should allow clients to request extra fields individually
> * Servers should allow clients to request packages of extra fields
> * Servers should explain the extra fields/packages available
> * Servers should not return extra fields without being asked
> * Clients may request extra fields at any time
> * Client identification is an extra field
> * Server identification is:
> 1. In the explain record
> 2. An extra field in any response
That's my take.
> If so, then that's good, because that's the status quo :)
Yup. It is gratifying to find, at the end of this, that the
mechanisms we all contributed to putting together so painstakingly
really do answer the need.
The only missing part was an actual extraData pair to carry the
information, which I proposed earlier in the discussion and which I
reproduce here for convenience:
<extraRequestData>
<ident:clientInfo xmlns:ident="info:srw/extension/1/ident">
<institution>Texas State Libraries and Archives</institution>
<vendor>Index Data ApS.</vendor>
<application>YAZ command-line client</application>
<version>2.0.35</version>
</ident:clientInfo>
</extraRequestData>
<extraResponseData>
<ident:serverInfo xmlns:ident="info:srw/extension/1/ident">
<institution>Library of Congress</institution>
<vendor>Endeavor Information Systems Incorportated</vendor>
<application>Voyager</application>
<version>0.01</version>
</ident:serverInfo>
</extraResponseData>
_/|_ ___________________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ Archosaurs rule!
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
|
