SODA gripes (2): Gratuitous xtypes

[Markus Demleitner]

Dear DAL,

In order to get on with my list of gripes, here's my second one.  In
two sentences:

SODA should not define any xtypes.  That's DALI turf.

The concrete consequence: All specifications of xtypes except the
interval should go from SODA standard parameters.

The reason simply is: They serve no purpose.  In the case of POS, not
only do they serve no purpose, they're actually damaging.

Here's the background on xtypes: xtype is a VOTable attribute to
FIELDs and PARAMs introduced in (I think) 1.2 because there was
resistance to extending the VOTable type system to some types that
were found desirable when delivering database tables, in particular
timestamps and geometry values.

Retrospectively, I think it was a mistake to do this, because in the
end, it just confuses VOTable's type system, and VOTable
implementations will have to do something with all the types we're
defining anyway or we have a major interoperability problem on our
hands.  It'd have been much better to be honest about the feature
creep and extend the type system in VOTable itself.

While that ship has sailed, it's important to limit the damage: let's
at least be very cautious when introducing new xtypes lest we make
VOTable unimplementable.  There should be exactly one place in which
xtypes are defined.  It seems that one place is DALI.

In SODA, since we now have interval-typed parameters,
xtype="interval" must be there, or clients have now way to find out
whether something should end up as a, say, slider or it's really two
numbers not otherwise related to each other.

All other xtypes are gratuitous and should go.  This concerns 

* ID's xtype="ivoident"
* POL's xtype="Stokes" (or "stokes"; the draft proposes both)

These serve no purpose I can discern.  What would clients do with
them?  Instead, they just pose traps into which services will fall
when they're validated -- services that otherwise perfectly work.
They'll also be points of confusion when implementors ask themselves
what they should possibly to with these xtypes.  I solemnly proclaim
that I won't be the one to stand up on the mailing lists and explain,
they're not supposed to do anything to VO newcomers.

Even more importantly, The xtypes in 

     <PARAM name="POS" ucd="phys.angArea;obs" datatype="char" 
      arraysize="*" xtype="circle" />
     <PARAM name="POS" ucd="phys.angArea;obs" datatype="char" 
      arraysize="*" xtype="range" />
     <PARAM name="POS" ucd="phys.angArea;obs" datatype="char" 
      arraysize="*" xtype="polygon" />

must go, and there must only be one PARAM definition per name.

Frankly, if I saw a construct like this I'd guess it was part of a
validation suite to see if a client rejects multiple definitions of
the same PARAM.  What kind of data structure should a client parse
such a definition into?  What would it do with the result?

The circle and polygon xtypes (range I don't think we want) will, I
suppose, be defined by DALI 1.1 for the annotation of columns
of that type (what's now adql:POINT or adql:REGION, etc., as per TAP).

POS, on the other hand, is alphabet soup by design, and back in
Madrid when I tried to argue against it (clearly unconvincingly),
people insisted they need alphabet soup.

Fair enough (and it's possible to, with some caveats, deal with it),
but then we must not lie about it being simply alphabet soup.
Eventually, we're dealing with computers here, and remember the old
saying

  If you lie to a computer, it will get you

                      -- J. Bentley, 1988

Also, if I understand Pat's plans correctly, the geometric xtypes
will be datatype="float" or "double" and arraysize="3" or "<something
like *>", so we're not even just lying about POS' nature, we'd also
by lying about the actual content.

So, I claim that parameter definition should simply be

  <PARAM name="POS" ucd="phys.angArea;obs" datatype="char" 
    arraysize="*"/>

[incidental wish: to give a good example, this should include a nice
and clear DESCRIPTION element -- SODA PARAMs SHOULD never come
without DESCRIPTION]

Cheers,

              Markus