Yes, I agree with Rob that we should use our naming convention for the SRU
extension.

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').

I would prefer this approach, even though such subclasses might never be
defined; it seems more flexible.  Any opinions?

--Ray



----- Original Message -----
From: "Dr Robert Sanderson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, January 04, 2005 4:16 AM
Subject: Re: Betr.: Unsolicited response data (Re: British Library Test SRU
Service)


> > I expect that this extension will be in the future be used quite often
> > for sru clients, so lets keep the sru parameter name/value short, e.g
> > -x=ok.
>
> That would be giving this particular extension a lot of preference over
> any other.  While it's up to Ray to define the parameter name, there's no
> reason to break with the naming scheme we already have for extensions
>
> (x-info-<owner>-<name>)
>
> > restricted by the limited capabilities of static clients. I anticipate
> > clients that can be adapted by the user to fit the users needs based on
> > what a server may have to offer.
>
> And the same applies here as my previous messages ... if the client can
> handle it, then the client can request it.
>
> Rob
>
>        ,'/:.          Dr Robert Sanderson ([log in to unmask])
>      ,'-/::::.        http://www.o-r-g.org/~azaroth/
>    ,'--/::(@)::.      Dept. of Computer Science, Room 805
> ,'---/::::::::::.    University of Liverpool
> ____/:::::::::::::.  L5R Shop: http://www.cardsnotwords.com/
> I L L U M I N A T I