[SIAv2] query params

[François Bonnarel]

Hi Markus, all
     Trying to concentrate on one issue.

    -  You say we need free parameters , either in free services such as 
those intended in DataLink or in free extension in standard interfaces. 
I am not sure we need the latter for query interfaces (probably more 
obvious with AccessData interface) but anyway i don't want to disput 
this point here. We do need free parameters and  a mechanism to describe 
them.
     - You say that if we can describe these free parameters we should 
be able to describe the standard one the same way. I think I agree with 
that.
     - By the way , free services or queries using free parameters may 
be attached to a single dataset. At least have ranges or predefined list 
of values dependant from the dataset. The parameter description should 
allow this
    - I understand your MAIN concern is about using string-typed input 
parameters with a complex structure. Something you will have to parse. 
But in the real cases we have, such as those dealing with some given 
axis coordinates we have very limited variabality. The kind of stuff 
proposed by Pat with direct values, RANGE, CIRCLE and / is not that 
difficult to formally describe and parse. For me the main advantage of 
this is that we have a very simple correspondance 1 quantity / manged by 
a single parameter. Before going to study alternative solutions (based 
for example on combinations of basic-typed atomic parameters) I would 
like people to comment on this.
                * do they really dislike the string valed input 
parameters with some structure to parse ? And if yes why ?
                * do they have other solutions to buidl this structure 
than the ones proposed so far.
Cheers
François
Le 02/12/2013 10:36, Markus Demleitner a écrit :
> 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