empty param values in votable

[Dubois-Felsmann, Gregory P.]

This thread is very timely.  Serge Monkewitz and I have just this week been puzzling over this issue in the context of what I agree is the sort of slightly awkward re-use of `PARAM` in DataLink.

We were trying to understand whether it's possible to communicate in a service descriptor that a parameter is optional vs. mandatory in the associated service call, especially if an empty string is also to be considered a valid value for the parameter.

This could be relevant to an SIAv2-like DALI API where a query parameter, if present, specifies a restriction (e.g., "DPTYPE=image"), and the service author would like to make it possible to select records where the corresponding parameter is NULL or empty.  That is, what if we want specifying "XYZ=" (with an empty value) to mean something different from not including the XYZ parameter at all?

Gregory

________________________________________
From: apps-bounces at ivoa.net <apps-bounces at ivoa.net> on behalf of Tom Donaldson <tdonaldson at stsci.edu>
Sent: Friday, July 17, 2020 7:01 AM
To: apps at ivoa.net
Subject: Re: empty param values in votable

Hi All,

I concur with the opinions here that value="" is OK according to the spec, and certainly should be allowed in this case.  I think the error from Astropy's parser may have been unintentional, partly influenced by the lack of clarity between NULL and blank strings.

To follow the initial issue report, see this Astropy votable issue: https://github.com/astropy/astropy/issues/10572

Since we've discussed NULL versus empty strings before, including the inconsistency between TABLEDATA and BINARY formats, I'm thinking we should file an issue  to clarify the intent on our document repository:  https://github.com/ivoa-std/VOTable/issues
I will probably get around to that in the not too distant future, but I would definitely welcome that from someone else!

Cheers,
Tom


On 7/17/20, 5:12 AM, "apps-bounces at ivoa.net on behalf of Markus Demleitner" <apps-bounces at ivoa.net on behalf of msdemlei at ari.uni-heidelberg.de> wrote:

    External Email - Use Caution

    Hi Carlos,

    On Fri, Jul 17, 2020 at 09:44:47AM +0200, Carlos Rodrigo wrote:
    > the astropy people have found an issue in one SVO service votable and I am not sure if I understand
    > the VOTable standard about this.
    >
    > The main point is:
    >
    > <PARAM name="INPUT:Instrument" datatype="char" arraysize="*">
    > <VALUES>
    > <OPTION name="All" value=""/>
    > <OPTION value="90prime"/>
    > <OPTION value="AcqCam-N"/>
    > </VALUES>
    > </PARAM>
    >
    > is correct? Is it valid to specify value="" for an OPTION element?

    The schema says that @value is xs:string, and, by XML Schema, the empty
    string is a valid literal for xs:string.  In the document, I cannot
    find prose that would further constrain @value, so yes, that's
    perfectly fine.

    As usual in VOTable, we have a NULL problem; in VOTable TABLEDATA,
    which is (or so I like to claim) what governs the serialisation of
    PARAM/@value and friends, we do not discriminate between the empty
    string and the NULL.  However, here we might, as what we're
    describing is an input parameter, and NULL might mean "leave it out",
    whereas an empty string would be "pass Instrument=" (which,
    incidentally, would be treated identically by anything building on
    the default behaviour of Python's cgi.FieldStorage...).

    For PARAM, I'd say a NULL can be represented without excessive
    nerve-wracking using VALUES/@null, whereas there are probably many
    cases where we want an empty string.

    Hence, I'd say we should make it clear somehow that an empty string
    in a PARAM/@value is an empty string and not NULL.

    > A related question:
    >
    > Is it valid to write:
    >
    > <PARAM name="Instrument" datatype="char" arraysize="*" value=""/>
    >
    > that is, specifying an empty value for a PARAM element?

    Again, a clear yes.  The use of this in Datalink, however, may
    suggest that we have it in dangerous vicinity of NULL there.  Ah
    well.

    > And, a last question, having a VALUES sub-element replaces the need
    > of having a VALUE attribute for params?

    No, at least not yet.  A PARAM in VOTable must have a @value
    attribute (which, admittedly, makes it a clumsy tool for the
    declaration of input parameters, as happens here).

    We could have said that a missing @value means "NULL", and, enemy of
    VALUES/@null that I am, I personally think we should.  But we
    haven't, and the current schema is clear about that: @value has
    use="required".

              -- Markus