[SIAv2] query params

[François Bonnarel]

Hello Markus,
     Well, you introduced a very rich discussion with a lot of different 
aspects.

      The starting point by Pat was the "standard parameters" for 
SIAV2.  (This is where I thought VOSI extensions with better parameter 
structure definition should be enough)

      In your answer you actually address the point of description of 
query parameters in general. And your intent seems actually to describe 
   free services (like the one we want to have in DataLink) or 
"extension  parameters" in Query (or presumably later AccessData) 
interfaces.

           *  I agree that something like "FORMAt=METADATA" response is 
needed. Or even simpler: response to an "empty" query ( root URL without 
parameters)
           *  I think there are pros and cons to have VOTABLE responses 
or xml (VOSI-like) responses. Others will probably comment.
           *  For complex types my alternative to the "multi-level GROUP 
encapsulation of several atomic parameters with fixed metadata" (VO-DML 
in PARAMETER typing context) is
                       . use regular expressions . this is universal and 
very generic. Use xtype on the PARAM (if we have chosen VOTABLE as the 
service auto description format)
to define it. Something like xtype="expression:[0-9]*\/[0-9]*"
                       . metadata problem ? We have to list the use 
cases for that. I see only one at the moment (but probably I miss a lot 
of them) It is the coordinate system. For this one, in case it's not 
fixed by the protocol a specific COORDSYS=.... parameter will work.
                Probably, I miss some tricks. But I would encourage to 
look for "flat" solutions like that

Thank you for the discussion, Markus
Cheers
François

Le 27/11/2013 15:04, Markus Demleitner a écrit :
> 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
>