[SIAv2] query params

[François Bonnarel]

Hi Markus
Hi all,
     About all this (and previews emails from Markus on this param 
definition topic). I think there are two things to distinguish.
       - description of FIELD types in query reponses. That's where 
xtype could be usefull. The VO-DML description issue for utypes belong 
to this too.
        - description of the Query parameters and of the complex type of 
this parameter. SO Markus propose to do this in a VOTABLE, by using the 
PARAM element. The abstract type of this element is given by VO-dml 
oriented GROUP structure.
           My question: do we really need a "data model" in general to 
describe the type of these data ?  Space time corrdinatyes is a special 
case.
           Here we are facing the problem of describing Standardized 
parameters for a service. This work is done by Registry xml documents 
such as descfribed in VOSI.
           Maybe we need some extensions to this mechanism to be more 
complete. If metadata are needed to interprete the param value, some 
reference mechanism could probably be added in the xml. VO-DML VOTABLE 
outputs could probably be compatible with the xml version. I see this as 
two different formats if wanted. But this
          is definitly a Registry issue for standarized services such as 
SIAV2
Best regards
François
Le 25/11/2013 21:41, Markus Demleitner a écrit :
> 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
>