But why not specify each new parameter at the time it is needed? How
does extraRequestData "prepare" anything for unforeseen extensions. I
can see that in the SRW the toolkits need to have an extraRequestData
container tag for all unknown input parameters, but in SRU that is not
needed. The server just ignores what it does not understand, echoes
parameters with an x-prefix and process the rest.
>>> [log in to unmask] 3-12-03 15:53:51 >>>
extraRequestData allows SRW/U to be extended in unforeseen ways. It
envisaged that it will be used for things other than onSearchFail such
unspecific data that needs to be echoed, authentication tokens, etc.
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
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
this only on request.
Thus: we need a x-parameter telling the server he has the permission
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
do not understand this parameter. As soon as more implementers like
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
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
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
we could also keep it as simple as above. Or am I missing something?
>>> [log in to unmask] 3-12-03 13:51:38 >>>
> Thanks, but I was looking for the exact use of extraRequestData in
> 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 :)
"The profile designer should also include a parameter name beginning
'x-' for use with SRU. The SRW/U protocol will never include an
parameter with a name beginning with 'x-'. It is suggested, but not
required, that the parameter name be x- followed by an identifier for
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
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
own copy, so I can send them all to be posted easily enough.
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I