empty param values in votable

[Tom Donaldson]

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