Working Draft - Simple Cone Search, v.1.1 2020-08-28 - released
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Wed Sep 2 12:50:37 CEST 2020
Hi Marco,
On Wed, Sep 02, 2020 at 09:49:41AM +0200, Molinaro, Marco wrote:
> Still I have a small concern about MAXREC=0 reading DALI-1.1
> section 3.4.4, second half of it.
> It seems that
> - or we clearly state that MAXREC=0 in ConeSearch should avoid
> request execution (because there's a risk of failure there)
> - or we touch slightly DALI avoiding MAXREC=0 to fail
>
> I'd say the first is simpler and safer, but, in both cases, since
> DALI simply says "containing metadata" without any further detail,
> there's the need to detail the metadata response solution.
Well, I understand that in general it's a good idea to improve
robustness by cutting down on dependencies, but in this case I'd say
the win is negligible: A client requesting MAXREC=0 probably does
that because in the next step it wants to run an actual query. If
that later query fails, nothing is won if MAXREC=0 succeeded.
The only scenario I could see where a more robust MAXREC=0 operation
might improve things is for metadata harvesting. But there I'd say
we shouldn't do that through SCS anywey -- we have the Registry,
vs:ParamHTTP, and OAI-PMH for that kind of thing, and if there's
anything missing from that combo that MAXREC=0 can do, we ought to
fix the combo rather than harden MAXREC=0.
So: +1 for just referencing DALI, plus regulations on how the input
parameters should be represented. For that second part, I'm a bit
undecided: We could copy what SIAP and SSAP do -- works, but feels a
bit stuffy --, or we could borrow from Datalink and have the input
parameters in a dedicated GROUP of a separate, non-result, RESOURCE
(which is a bit less hacky, but of course different from S*AP).
Hm...
-- Markus
More information about the dal
mailing list