On Mon, 11 Oct 2004, Theo van Veen wrote:
>>>>> [log in to unmask] 8-10-04 21:13:03 >>>
>> That if the client isn't expecting it, it could blow up the poor
>> unsuspecting client. Especially in thin (terminally stupid) clients.
> I thought that the nice thing of extraResponseData was that it was the
> right place to put "unexpected data" without blowing up the client.
It is. It lets us do it at all, as opposed to putting it directly into
the response which would never get past a SOAP toolkit.
> Given the discussion on expanding searches with the aid of thesauri I
> would be in favour of a protocol extension that indicates for a search
> result that the search returned a thesuarus term that can be expanded
> and extraResponseData seemed to me the right place for it.
Sure. I'm in favour of it too, and extra*Data is the right place for it.
Something similar would also be useful in scan.
> Although I agree with the general idea of not returning unrequested
> information ...
Good :)
> ... I think that this is a case were it could be appropriate to
> do so.
Why? What makes this more special than, for example, returning a unique
identifier for a record in extraRecordData?
Or an authentication token in extraResponseData?
> The alternative is that a user always has to request query expansions
> without knowing whether there are thesaurus terms resulting from his
> search.
And that's exactly the way it should be. If the server supports
fb.broader or fb.equivalent, it'll say so in the ZeeRex record. It should
also then say which thesauri it supports.
So then you need to ask the server to tell you that there were hits in
the thesaurus. Nothing wrong with that.
Rob
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. University of Liverpool
____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I
|