SODA gripes (4): Mandatory multiplicities considered harmful

[Markus Demleitner]

Hi Pat,

On Wed, Feb 10, 2016 at 03:13:28PM -0800, Patrick Dowler wrote:
> note: The multiplicity in DataLInk is also there strictly as an efficiency
> mechanism. You can enforce MAXREC=1 and indicate with an OVERFLOW if you
> don't want to do it. But with SODA if you don't want to support
> multiplicity just don't provide an async endpoint.

Well, yes, but it still prevents a simple and generic XSLT stylesheet
for datalink responses, which, given the sluggish uptake on the
client side, would be a nice thing.  And it still is extra
implementation effort (the service needs to check for a second ID and
generate the overflow indicator if it's there), and I'm still not
convinced there's a proportional benefit.  But as I said, that's for
another day.

As to async in SODA being optional: I can have good reasons to have
an async endpoint just for a single result (perhaps a cutout may be
slow, perhaps I'm doing a complex calculation).  Making me invalid if
I provide a filtering parameter but don't allow multiple values
because it really doesn't make sense to me but does make my life
harder seems unwise.

Can't we just turn it the other way round?  If you really think your
users need multiple intervals, provide it, and provide it with
whatever semantics makes sense for your particular set of parameters
and your particular community (and the clean solution, upload of a
parameters table, for some reason doesn't work for you).

And again, we should think hard if this[1] is a common enough problem to
warrant a temporary solution as pondered in my original mail or if it
can wait until we have a proper, VOTable-embeddable parameters DM.

Cheers,

          Markus

[1] and IMHO the more pressing problem, the support of the selection
of a proper input widget in clients when you have enumerated
parameters.