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:
http://krait.kb.nl/cgi-zoek/srw.pl?
and
http://krait.kb.nl/cgi-zoek/srw.pl?flg=sru&
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.
BTW.
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
issues.
Theo
>>> [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
constructing the
> > XCQL for the response.
Hmmm. I'm somewhat convinced, but these are private extensions. IMO
it
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
I
know.
On the other hand, this is only in extraRequestData (both in the
request
message, and the echoedRequest) and not in
extraTerm/Record/ResponseData,
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.
For
example if we were to introduce a foo parameter in version 1.2 and
someone
had been using 'foo' as their private extension, then there'd be a
conflict.
Note that echoedRequest is /optional/ even in SRU. You can't trust
that every server will echo everything. That said, I would expect that
if
servers handle extraRequestData, then it's not hard to echo it back.
They
also may not echo requests that they don't understand.
I would be wary of doing something like putting application data into
an
x-pleaseEchoMe field to maintain some sort of state. For example, you
want to redisplay the database name, so you send a request like:
http://...?query=fish&x-databaseName=Test%20Database
just to have the name in the response.
(As a server admin, I'd be less than pleased with such client
behaviour)
> There was an argument in version 1.0 that the parameter name could be
an
> invalid XML tag name and for that reason the parameter name was put
in
> <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
receive
broken xml or a diagnostic for their foolishness :)
It is a trap for unwary server writers though. (Rob goes off to fix
that
bug in his code now, where one badly named extension would trash the
rest
of them as well)
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
|