Yes, I agree with Rob that we should use our naming convention for the SRU
So we could call it:
However we could instead call it:
where there is a value, i.e. 'any', thus the parameter:
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
I would prefer this approach, even though such subclasses might never be
defined; it seems more flexible. Any opinions?
----- 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
> > 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
> > 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.
> ,'/:. 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