Date:         Tue, 4 Jan 2005 16:15:46 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      Betr.: Re: Unsolicited response data
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline

>>> [log in to unmask] 04-01-2005 15:20 >>>
>> -----Original Message-----
>> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]] On
Behalf
>Of
>> Ray Denenberg, Library of Congress
>>
>> So we could call it:
>>
>> x-info-1-acceptAny
>>
>> However we could instead call it:
>>
>> x-info-1-accept
>>
>> where there is a value,  i.e. 'any', thus the parameter:
>> 'x-info-1-accept=any'.
>>
>> This would leave room to later define other values, subclasses,
>> which could be profiled.   Would this be preferable (and if so
>> I would change the name of the info uri from
>> 'info:srw/extension/1/will-accept-any-extra-data' to
>> 'info:srw/extension/1/accept').
>
>Ick.
>
>If the SRU parameter is supposed to map to a URI, then what does the
>structure URI=value mean?
>
>Stick to x-info-1-acceptAny
>

Having a value is more flexible, because it allows refinement in the
future, e.g x-info-1-accept=hints or x-info-1-accept=not_too_much.

Theo