[SIAv2] query params

[Markus Demleitner]

Dear DAL list,

On Tue, Nov 26, 2013 at 05:28:21PM +0100, François Bonnarel wrote:
>        - 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.

Well, people -- not only Pat -- have argued we have to allow complex
types in query parameters (and elsewhere).  I have argued that if
that is so, we need to make these types explicit.  If both statements
are true, we'd need something that more or less as proposed.

Again, *I* think the SSA experience should tell us to 

(0) keep things extremely simple, and that we should go for _CENTER,
_SIZE and friends for structure and UCDs for, ahem, modelling (and
rejoice if all data providers finally get the UCDs right).  In this
world, no, we'd not need to worry too much about data models behind
parameters.

But if the complex types crowd is right and the choice is: 

(1) A host of vaguely documented, implicit types with ill-defined
semantics (what's a string range?  How should step work with
floats?), unclear applicability to custom parameters, and a severe
lack of metadata (so... LAMBDA is as string parameter!?)

or

(2) VO-DML for types and clear, standard VOTable markup for the
PARAMs

-- *then* I'm going for (2) any day, even if I think we could (and
maybe should) technically get away with (0).

>           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.

No and no.  First no, this is not only about standardized parameters.
People will want extension parameters, and frequently (as for the
theoretical SSA services) those are the really interesting ones.  The
way things are now in SSA, clients have little chance figuring out
how to operate them, and that's really, really a pity.  Even services
that have basically identical parameters (log_g, say) cannot be
operated in parallel, since the clients have no way to figure out
it's the same physics (lack of UCDs) and they could only guess if
the service expects/supports PQL syntax and/or has some sort of
MIN_/MAX_ convention in place -- not to mention the absence of
information on ranges covered by the service.

And as second no, this work is not now done by registry XML
documents (at least not primarily).  Both SSA and SIA have
FORMAT=METADATA requests that discover exactly this kind of thing.
You might argue these shouldn't have been there to begin with, and
that they should go away, with clients harvesting from the
capabilities endpoint (I don't think grabbing this info from a
searchable registry is in the competition for this kind of thing)..

I might even agree.  But until we abolish it FORMAT=METADATA seems to
me the primary way of metadata discovery (it's extremely convenient
to both the client and the server, even if it's not actually got a
strikingly pretty face).  And don't get me started on the
capabilities endpoints of the vast majority of services out there --
the METADATA queries at least work for most of the services.

>           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

If we agree on the types and have a VO-DML, I suppose it wouldn't be
too hard to add some lightweight markup for generic XML documents
(maybe inspired by RDFa) that allows embedding VO-DML instances
there, it that's needed.  But let's first figure out what it is that
we want to express.

> 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

No, it is not.  Postponing such central questions as "How do my
clients discover the service metadata?" (which includes things  like
"What magic strings are allowed for that nice 'FLUXCALIB' parameter?"
or "For what values of RA_MAX do I have a fighting chance to find
data?") to some registry document to be written Real Soon Now is a
recipe for protocols for which it's *very* hard to write clients with
a gratifying user experience.


Since I'm still not sure we're arguing about roughly the same things:
Do you disagree that SIAv2 clients should, as a rule, be able to make
informed suggestions for parameter values -- regardless whether the
parameters are core or extension -- once it has read the server
metadata in a suitable form?  

So you disagree that the standard should speak about how custom
parameters should work such that clients can sensibly operate
serveral services, each exposing similar physics, with one UI?

If not: What else do you propose as a mechanism for doing this if you
do not like the proposal to use atomic (i.e., native VOTable-typed)
PARAMs (ordered into a VO-DML structure for the smarter clients)?

And a final "no", that's not a rhetorical question.  I'm honestly
interested, and maybe there's a way that's an easier sell and still
not overly complex after all.

Cheers,

         Markus