[SIAv2] query params

[Markus Demleitner]

Hi list,

On Mon, Nov 25, 2013 at 09:26:21AM -0800, Patrick Dowler wrote:
> On 11/18/2013 04:54 AM, Markus Demleitner wrote:
> >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.
> 
> Yes, I agree that in the longer term if adopted these should also
> result in new VOTable datatype(s). The xtype usage for TAP went only

Well, the great thing about my proposal to just use VO-DML (which is
made exactly to define complex data types in VOTable) is that we
don't need to change VOTable at all (this is mainly to unruffle
Mark's feathers) and still have an extensible library of types.

> part way and is more complex than just defining the datatype(s) would
> have been. Still, that mechanism is there now and it could also be
> used for this sort of thing.

Hm -- the main sane use for xtype (I think most of us feel that
allowing all kinds of STC strings in a single VOTable column wasn't a
great design decision, so that doesn't count) is marking up strings
as datetimes; that's a bit different from what we're talking about
here as one could reasonably argue that that's metadata on an atomic
type, which fits pretty well for an attribute of field; some
descriptor of a complex type (meaning: consisting of several atomic
values) doesn't, does it?

Since you mention xtype: Do you have something in mind like

<PARAM name="LAMBDA" datatype="float" xtype="interval">
  <VALUES><MIN>4e-7</MIN>...

-- from which I client could deduce that "5e-7/" would be a valid
literal for that kind of float?

My first reaction: I wouldn't like it.  It's lying (5e-7/ simply is not
a float literal), and I doubt it'll work for much more than just
intervals.

Or did you think of 

<PARAM name="LAMBDA" datatype="string" xtype="float-interval">
  <VALUES><MIN>4e-7</MIN>...?

Might fly better, but it's still terribly ad-hoc when, as I tried to
point out, we have all we need for a clean, extensible solution for
which we'll have library support since it's needed for DM support
anyway.  For example, I'd consider MIN and MAX fairly I'll defined
for strings, and having to evaluate and know the xtype to be able to
interpret MIN and MAX kinda sucks.

> In either case, I am not particularly fond of defining these
> datatypes in a specific DAL protocol document. If the DM-WG were to

Where the ultimate standard is laid down is secondary. I'm pretty
sure that without a use case that's exciting to sufficiently many
people the thing won't get enough traction, though.  So, let's start
the types DM fragment within DAL -- *we* ought to agree what types we
think we need.  Writing the VO-DML once that's done is not a big
deal, and going from there to something that can end up in some
convenient standards document is something I volunteer for.

But first we need the types -- so, what are they?  Or are they,
perhaps, already defined in PDL?

[Now, I've always said the cube use case doesn't really need this
kind of thing at all, and we'd get by by UCDs and _MIN, _MAX and
maybe _CENTER and _SIZE parameters, plus of course *finally* an
adoption of STC metadata in VOTables; so don't point at me as to
listing the types, I'm just here to communicate the lessons I learned
from SSA]

> >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)
> 
> It is true that SSA (and this topic in SIA-2.0) implies some types
> but does not really come out and say it... but that is also true of
> ADQL-2.0 and is something that needs to be rectified. Still, we have
> been able to stumble along with TAP  :-)

Right -- the standard that actually used ADQL had to make explicit the
type system to make things work.  That was not good, and it's still a
weak part and constant source of confusion in the TAP/ADQL combo.

Let's not repeat old mistakes over and over.  Let's sit down and
do things right right away (as it behooves a version 2 standard).

Cheers,

         Markus