WD-AccessData-1.0-20140312

[Markus Demleitner]

Dear Francois,

On Mon, Sep 01, 2014 at 06:03:47PM +0200, François Bonnarel wrote:
>                   1 ) finite Interval              BAND = 5 / 6
>                   2 ) no upper limit interval      BAND = 5 / .
>                   3 ) no lower limit interval      BAND = . / 6
>                   4 ) single extracted value       BAND = 5.5
>           Parsing this kind of "language" doesn't seem more tricky than
>    managing the various combinations of atomic parameters we would need to
>    render all these flavors

While I've given up resistance  against soup in POS (or whatever
we'll end up the "cutout-spec-in-a-string" parameter), let me again
stress that my concerns are *not* about parsing this.  On the
contrary, if I were to design a soup language, I'd probably add more
syntax, and it appears other people are planning to do this, too (did
I hear about discontinuous intervals?).

No, the problem is metadata declaration:

* what are mins and maxes of these things?  In case of discrete
  types, what values can be passed it?
* what are their types? 
  * string? Can that have a unit?  And how do I tell them from "real" 
    strings? 
  * actual type (float, int...)?  Sucks for VOTable parsers if they see 4/6
    in what's supposed to be float.
* if (and people will want this) there's more syntax, how do we find
  out what of it a concrete service supports?

There are more interoperability problems that surfaced in SSAP
practice that can all be largely mitigated by atomic parameters.

And of course the *services* won't get much simpler with either
solution -- they have to explicitely model interval limits in
whatever way is convenient for them in both cases (and no, potential
parsing doesn't significantly add to that if the grammar and metadata
were well done).  It's the *protocol* we're saving a lot of headache,
toner/ink, and pitfalls in.

>           If the two  approaches are not reconcilable and we want to let
>    all this question opened in the hands of implementers we could  say

As I said, I think a POS soup allowing whatever cfitsio or SSA or
STC-S syntax appears palatable doesn't conflict with atomic
parameters -- it's just another parameter for which we essentially
say: "Metadata is much too complex to express with our basic VOTable
things; see the standard text and some advanced sort of metadata
represented in an agreed-upon place".

>          - I think there are strong benefits (and no real drawback) in the
>    long term to have the same syntax for SIA and AccessData.

Uh, let me dispute the "no real drawback" -- in a discovery service
like SIAv2 you *may* get away with sloppily defined metadata (don't
quote me on this, though, as I'm not actually sure we're always on
the good side of the "barely" that should be in front of the "get" in
that sentence).  

In a data access service -- that for most apparently useful
parameters will typically just return and empty array -- you don't.
Server-side data processing is a different beast than data discovery,
and an arguably more difficult one at that.

Cheers,

         Markus