[SIAv2] query params

[Markus Demleitner]

Hi all,

On Wed, Nov 13, 2013 at 10:05:59AM -0800, Patrick Dowler wrote:
> 
> Yes, the / separated range syntax was adopted from other (non-astro)
> syntax. IIRC, it is used in date ranges in ISO8601 and also in some
> successful GIS-related systems. Basically, you want to be ale to
> specify ranges and a non-space separator allows you to leave one or
> both ends unbounded.
> 
> eg:
> 
> 1/2 aka 1 to 1
> 1/  aka 1 to +inf
> /2  aka -inf to 2
> 
> It is part of SSA-1.x now and so far just one voice calling to
> abolish of such things :-) My opinion is that we need these more
> complex data types (intervals and geometry) as they concisely
> describe values we use all the time *and* adopting this approach
> makes for more robust software.

I will not dispute it would be great to have more complex types
represented as such in DAL protocols and -- in what I believe is a
necessary consequence -- VOTables in general.  I'm not entirely sure
the world is ready for this (inspecting actual SSA responses has not
been encouraging), but perhaps all that's this is telling us is that
we, as people defining the standards, have an obligation to provide
reference implementations in Java, Python (I volunteer for this) and
PHP as a minimum.

Be that as it may, my point is that ad-hoccing syntax (even if there
is precedence) is *not* a good way to define types (as again
witnessed by SSA; in particular see custom service parameters, where
data providers clearly were at a loss to see whatever type model was
implicit in SSA, and there's no way to communicate which what type is).

No, in every language (excepting possibly some abominations) you
define types by (...drum roll...) defining types!  It is a stroke of
luck that, right now, we are a defining a language to do just that in
the VO, and we get to a say what DAL needs from that language.  It's
VO-DML.

If there is actually a consensus that we need complex types in DAL
protocols, we should urgently sit down and

(a) collect a list of types we deem necessary, and
(b) in close cooperation with other data modellers define them (i.e.,
write up the VO-DML for them).

(b) is necessary as quite a few of the types (intervals, geometries,
geometries with reference systems, etc) can, should, and must be
re-used by the actual data models.  If such a rough consensus is
there, I volunteer to draw up something implementable by late
January.

In an (ad-hocced:-)  example, here's how a service would declare its
metadata:

<GROUP utype="partypes:floating-point-interval">
  <PARAMref utype="partypes:interval.hiLimit" ref="LAMBDA_MAX"/>
  <PARAMref utype="partypes:interval.loLimit" ref="LAMBDA_MIN"/>
</GROUP>
<PARAM ID="LAMBDA_MAX" datatype="float"...>
  <VALUES><MAX>34.2</MAX><MIN>22.1</MIN></VALUES>
...

The beauty of the scheme is that very simple clients can go by the
names (which the standard would fix), ignoring the groups.  Advanced
or generic clients can evaluate the groups (that could also carry
additional metadata) and get more insight into the parameter
structure.

And now here's the kicker, made possible by the new utype scheme (and
the reason I agreed to restrict the old utype syntax on FIELDs and
PARAMs): If you define a special data model for a protocol and the
parameter turns out to be in sia:observation.wavelength, you'd simply
say

<GROUP utype="sia:observation">
  <GROUP utype="sia:wavelength">
    <GROUP utype="partypes:interval">
      <PARAMref utype="partypes:interval.hiLimit" ref="LAMBDA_MAX"/>
      <PARAMref utype="partypes:interval.loLimit" ref="LAMBDA_MIN"/>
    </GROUP>
...
<PARAM ID="LAMBDA_MAX"  datatype="float"...>
  <VALUES><MAX>34.2</MAX><MIN>22.1</MIN></VALUES>

[Gerard: Please correct any of this if you think I'm grossly
misrepresenting what VO-DML could easily be extended to]
.
See how both the simple and the generic clients still work as above
by looking for parameters or GROUPs with special utypes, a generic,
datamodel-aware client can figure things out perfectly, and a
protocol-specific client can discover all the necessary metadata?  No
ad-hoccing of syntax, no implicit type definition, no extension of
the VOTable type system, just plain, clean, goodness.

What's not to like?

If I hear anyone mumbling "too complex": Well, try definining
parameter metadata for your string parameters.  I've tried for five
minutes, despaired and gave up.  More brilliant minds might come up
with something, but I dare to predict it's going to be much more
complex than the VO-DML-based makrup, in particular when you believe
for a moment that there are going to be generic VO-DML-enabled
VOTable clients.

Thanks for indulging me,

         Markus