I don't think we should care about local extensions: the use of the
x-prefix is a local responsibility. We have to keep in mind that some
"local extensions" are just part of the base-url. For example:
are considered two different services. The parameter flg=sru is not
considered a local extension parameter but a part of the base-url
pointing to another SRU-service.
Where can I find the current specs for 1.1? I have deleted too many
emails to reconstruct the specs from the emails and I would like to
point our implementors to the new specs for new SRU implementations that
are currently under development. I also lost the link to the list of
>>> [log in to unmask] 2-12-03 13:18:58 >>>
> > I don't understand why the "x-" is stripped. I would prefer:
> > <x-foo>1</x-foo>
> > Then there is no necessity for extra stripping code when
> > XCQL for the response.
Hmmm. I'm somewhat convinced, but these are private extensions. IMO
should be defined how to return it in XML form when the extension is
defined, rather than requiring x-foo top level elements.
Secondly, such stripping code isn't even an extra line in any language
On the other hand, this is only in extraRequestData (both in the
message, and the echoedRequest) and not in
so I can live with it.
> I agree with Janifer. The x- is currently only used to prevent a
> diagnostic from the server. All parameters are echoed. Am I right?
The x- is to prevent future naming conflicts with private extensions.
example if we were to introduce a foo parameter in version 1.2 and
had been using 'foo' as their private extension, then there'd be a
Note that echoedRequest is /optional/ even in SRU. You can't trust
that every server will echo everything. That said, I would expect that
servers handle extraRequestData, then it's not hard to echo it back.
also may not echo requests that they don't understand.
I would be wary of doing something like putting application data into
x-pleaseEchoMe field to maintain some sort of state. For example, you
want to redisplay the database name, so you send a request like:
just to have the name in the response.
(As a server admin, I'd be less than pleased with such client
> There was an argument in version 1.0 that the parameter name could be
> invalid XML tag name and for that reason the parameter name was put
> <ParameterName>. I guess this argument has lost importance?
Anyone who creates an extension that uses invalid xml element
name characters as part of the name of the extension deserves to
broken xml or a diagnostic for their foolishness :)
It is a trap for unwary server writers though. (Rob goes off to fix
bug in his code now, where one badly named extension would trash the
of them as well)
,'/:. 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