[SIAv2] query params

[Markus Demleitner]

Hi François, dear not-so-far-but-hopefully-soon-participants in this
discussion,

On Fri, Nov 29, 2013 at 02:56:14PM +0100, François Bonnarel wrote:
>      The starting point by Pat was the "standard parameters" for
> SIAV2.  (This is where I thought VOSI extensions with better
> parameter structure definition should be enough)

I don't believe there's much of a difference between standard and
extension parameters.  True, for the standard parameters you could
define some special rules in the standard text.  That still wouldn't
suffice to communicate legal ranges (for float-valued parameters) or
the enumeration of allowed/supported values (for parameters like
FLUXCALIB). 

And again: Extension parameters have been critically important in
SSAP, so I claim they should not come in as some afterthought in
SIAv2 (or any other such protocol, fot that matter).  Their use and
definition needs to be included in the service interface from the
start.

Now, if we need some mechanism to describe extension parameters, I'd
argue it should be good enough to be used for the standard
parameters, too -- no special rules in the text, less language in the
standard, less code in the implementation, profit all around.

This will also save us from horrors like the SSAP's BAND parameter
that could be a wavelength range, or some rough indicator of the
spectral range, or even some custom bandpass identifier.  When one
tries to use a formal language to describe something like this, one
immediately notices that this is something that shouldn't be done.

>           *  I agree that something like "FORMAt=METADATA" response
> is needed. Or even simpler: response to an "empty" query ( root URL
> without parameters)

I don't care about the concrete mechanism.  I admit I've never been a
big fan of the FORMAT=METADATA thing -- FORMAT is a big pain in
S[SI]AP already (e.g., 44 lines of hardcoded logic for SSAP-FORMAT in
DaCHS, and that's after FORMAT=METADATA has been filtered out by more
custom code before), and frankly I'd love to see FORMAT's function
going to datalink, letting FORMAT die anyway.

Even in the likely event that we'll have FORMAT in SIAv2, I'm all for
an alternative option.  Let's see what's in the race:

(a) FORMAT=METADATA (see above for my vote)

(b) Empty query (hasn't been tried yet, as far as I know -- doesn't
sound too bad for me; people who want to have HTML forms at that
URL need the metadata anyway, and XSL could produce the forms from
them)

(c) REQUEST=getMetadata (I personally think REQUEST shouldn't have
been defined, either; we should have had URL paths for the different
functionalities of a service.  Since I don't think we'll get rid of
REQUEST any time soon, we might as well use it)

(d) Normal query with MAXREC=0 (there's precedence for that; one cool
thing is that a service might actually evaluate the remaining query
and give ranges and values just for what *would* match, possibly even
giving some guesstimate of how much would match.  That'd be real nice
for input-completing interfaces and such.  Doesn't sound like
something I'd be crazy about implementing, though)

(e) VOSI capabilities (doesn't yet have the capabilities to
sufficiently describe the parameters.  But of course, we could easily
say "PDL fragment in here" and probably be done.  Having a PDL
implementation be something like an almost-prerequisite for a SIAv2
server feels somewhat steep to me, but then I've not implemented PDL
so far, so my judgement isn't worth much here)

(f) Your entry here.

Ladies and Gentlemen, please cast your ballot (or even better, utter
your opinion).  For me, my order of preference would be b, c, d, a,
e, where I'll defer the positioning of f to when your entry has come
in.

But let's only pick one of those.  It sucks to have to return the
same information, possibly with slightly different syntax and
semantics, on more than two places.  And VOSI capabilities is a MUST
already, just not in the detail we need, which means that one place
for parameter metadata is (almost) taken).

>           *  I think there are pros and cons to have VOTABLE
> responses or xml (VOSI-like) responses. Others will probably comment.

The main reason I'm in favour of VOTable is that (I claim) we know
how to embed STC metadata in there, and with VO-DML we'll be able to
do the same magic for other data models easily.  Of course, VO-DML
can also spit out XML schema, which could then be included, but
frankly that'd be much clunkier.  Plus, trust me, you don't want
STC-X in your parameter responses, much less when you SHOULD have
STC-in-VOTable in your protocol responses anyway.

>           *  For complex types my alternative to the "multi-level
> GROUP encapsulation of several atomic parameters with fixed metadata"
> (VO-DML in PARAMETER typing context) is
>                       . use regular expressions . this is universal
> and very generic. Use xtype on the PARAM (if we have chosen VOTABLE
> as the service auto description format)
> to define it. Something like xtype="expression:[0-9]*\/[0-9]*"
>                       . metadata problem ? We have to list the use

Hm, no, I don't like this.  Reasons:

(1) You still don't know the ranges.

(2) There's no semantics here.  In effect, a user interface can now
tell a user that s/he's wrong without a round-trip to the server, but 
has precious little knowledge to suggest anything that's right.
True, it can do a bit by parsing the RE, but I'd suggest that parsing
the VO-DML markup is easier than inferring some sort-of-semantics
from parsing an RE.

(3) There's nothing that keeps the next service operator from having
[0-9]*-[0-9]* for, say, the range of loggs, and that makes the job of
a client querying multiple services really hard.

(4) What about the datatype of such a parameter?  Do you have
datatype="int" xtype="expression:[0-9]*\/[0-9]*"?  Don't like it,
as what's passed in aren't integer literals.  Or would you have
datatype="char" arraysize="*" xtype="expression:[0-9]*\/[0-9]*"?
Like it even less, as a client will only find out that the underlying
thing is an integer if it parses out the RE and is smart on top of
that.

(5) What happens for datetime-valued-parameters, or indeed much
anything else that might need the xtype some day -- does this mean
you can't have ranges of datetimes?

(6) There's five reasons why I don't like it.

Cheers,

         Markus