I do not think we disagree, but imo we should try to follow these
principles as much as possible. I am reasoning from the perspective that
the list of targets is dynamic and client and servers have hardly no
knowledge of each other.
Ofcourse we need diagnostics to let the server say "I cannot do this"
but I would like the server to return something useful in addition to
this diagnostic. The xPath is a nice example.
Suppose I prefer title, author date as response and I want to broadcast
a query to several targets. I do not know what schemas they have
available. I would like to say to the servers "give my title, author and
date (by means of xPath) but if you cannot do that give me your captions
(default) and I will try to make something out of it". I assume that a
caption will not be 25 Mb there is no guarentee.
The only thing we have to agree upon is that in this case the server
returns something useful in addition to the errormessage e.g. a short
DC(X)caption.
Suppose that we introduced the xPath feature when there are already
lots of implementations. In that case I prefer the above approach rather
than having two incompatible versions of the protocol. Getting the
correct diagnostics instead of a useful response is by me often
"perceived" as incompatibilty.
Theo
>>> [log in to unmask] 8/6/03 12:55:42 nm >>>
> > 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
> so.
Diagnostics are easier to implement than fudged results anyway! If
you're
not going to implement the feature at all, then you might as well take
the
easiest route out ... a diagnostic.
> 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).
I agree with Mike (and Matthew's original post) completely.
Some other reasons: echoedRequest/unknownParameter is only available
in
SRU. Meaning that SRW and SRU would have different semantics about how
to
deal with unimplemented features.
Some features won't be checkable by the client via inspection. For
example various types of sort. So the client would never know if it
was
performed or not.
Sometimes the client will be making the good faith assumption that the
server will either give a diagnostic or perform the request as asked.
For
example I might search a database full of megabyte+ records and ask
for
/record/title | /record/creator in the XPath with a maximumRecords of
25.
If the server just returns the full 25 megabytes+ of records, then
chances
are likely that the client will choke (quite apart from being a total
waste of time and resources).
For small records, you might as well retrieve the whole thing. XPath
is
useful for extracting sections of large records, or for paging through
a
single record that's too long to conveniently display at once.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: telnet: nebmedes.o-r-g.org 7777
____/:::::::::::::. WWW: http://nebmedes.o-r-g.org:8000/
I L L U M I N A T I
|