Date:Wed, 3 Dec 2003 15:53:51 +0100
Reply-To:"Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:"Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:Janifer Gatenby <[log in to unmask]>
Subject:Re: Unknown Params in SRU
Comments:To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type:text/plain; charset="iso-8859-1"
extraRequestData allows SRW/U to be extended in unforeseen ways. It is
envisaged that it will be used for things other than onSearchFail such as
unspecific data that needs to be echoed, authentication tokens, etc.
Janifer
-----Original Message-----
From: Theo van Veen [mailto:[log in to unmask]]
Sent: 03 December 2003 15:15
To: [log in to unmask]
Subject: Re: Unknown Params in SRU
Perhaps we should do one step back befor making things more complicated
than needed.
Lets look at the following scenarios:
Server A has a nice feature to provide extra data. Although I would
send this extra data unsollicited we agree that well behaving servers do
this only on request.
Thus: we need a x-parameter telling the server he has the permission to
do so. As this parameter is prefixed with x- we may send it to any
server. Other servers will optionally echo but nothing more because theu
do not understand this parameter. As soon as more implementers like this
parameter it can be proposed for the next version of SRU.
Now we have a specific parameter "onSearchFail". When it is
"x-onSearchFail" our server can respond in its own way. But when we
agree that onSearchFail is a valid parameter lets treat it like that and
just specify it in SRU/W. We can restrict the possible values to an
agreed list, like 'do scan", "do fuzzy" etc. Private or local values can
be "x-do whatever" and may be neglected by other servers.
I do not see a reason for extraRequestData when we have defined
onSearchFail as a valid SRU/W parameter.
I'm afraid we introduce a lot of complexity that will not be used while
we could also keep it as simple as above. Or am I missing something?
Theo
>>> [log in to unmask] 3-12-03 13:51:38 >>>
> Thanks, but I was looking for the exact use of extraRequestData in
SRU
> and I can only find it for SRW. I'm lost on the relation between the
> x-prefix and extraResponseData.
I hadn't written it because there wasn't any agreement yet on it :)
Currently:
"The profile designer should also include a parameter name beginning
with
'x-' for use with SRU. The SRW/U protocol will never include an
official
parameter with a name beginning with 'x-'. It is suggested, but not
required, that the parameter name be x- followed by an identifier for
the
profile, followed by the name of the element. For example
'x-theo-onSearchFail' for <theo:onSearchFail>.
If the contents of the parameter is an XML structure, then the profile
designer should also specify how to encode this structure for SRU.
This may simply be to escape all of the special characters, but the
designer could also create a string encoding form with rules as to how
to generate the XML in much the same fashion as the relationship
between CQL and XCQL."
I don't think anyone disagrees with this, right? It's when the server
receives an unknown x- parameter and needs to echo the query back
where
there's no firm consensus?
> Will the information from the above link be copied to the ZING
> webpages? I prefer to have only a single website to point
> our implementors to.
I expect so. I've incorporated Ray and Jannifer's changes back into
my
own copy, so I can send them all to be posted easily enough.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I
