> Date: Wed, 6 Aug 2003 09:52:27 +0200
> From: Theo van Veen <[log in to unmask]>
> Maybe I missed a part of this discussion, but I think we should try
> as much as possible to apply a third criterium for accepting new
> features in SRU/W and that is:
> 1) that when a client ask for this new feature a server that did not
> implement this feature should be able to give a "reasonable"
> response - not being an error message.
> 2) that when a server provides a new feature the client should be
> able to neglect this when he is "not aware" of this technology.
Hi, Theo. I agree with your second criterion, but certainly not the
first. If we are to enable SRW to provide solid, reliable services,
then the one thing they mustn't be allowed to do is fudge the issues.
If I ask a server to so something a certain way, it must not be at
liberty to ignore that and do it a different way. It is only polite
for a server that can't honour my request to come right out and say
> In this way we improve backwards compatability and robustness.
And unpredictability :-)
> In the case of xPath there is an easy escape (not a diagnostic) for
> servers that did not implement this by providing just ordinary
> captions or complete records (whatever is the default) and returning
> the xPath parameter as "unknownParameter".
This is less offensive than _merely_ ignoring the XPath parameter, but
still not really great. What it means is that XPath-aware clients
would need, every time they submit an XPath'd search, to explicitly
check whether the XPath was honoured (silence) or ignored (included as
an unknownParameter in the response).
Worse, clients would need to perform similar ad-hoc checks relating to
_each new feature_ they tried to use. Much easier, surely, just to
have it make a single check for the "I couldn't do this" error-code?
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ Live fast, Die old.
Listen to my wife's new CD of kids' music, _Child's Play_, at