Arrays of geometries?

[Markus Demleitner]

Hi Dave,

On Wed, Sep 06, 2017 at 07:05:40PM +0100, Dave Morris wrote:
> In an earlier discussion Markus suggested using a language feature to
> indicate whether a service supported arrays.
> http://mail.ivoa.net/pipermail/dal/2017-July/007736.html
> 
>     <languageFeature type="ivo://ivoa.net/std/TAPRegExt#features-arrays"/>
> 
> I'd like to build on that and define two features within that URI to
> indicate support for numeric and geometric arrays.
> 
>     <languageFeature
> type="ivo://ivoa.net/std/TAPRegExt#features-adql-arrays">
>         <feature>
>             <form>numeric</form>
>         </feature>
>         <feature>
>             <form>geometric</form>
>         </feature>
>     </languageFeature>

Hm -- I'm not sure I like this.  For one, there are non-geometry
xtypes (currently, timestamp and interval), and you'd have to
declare support for these, too, if we go down that road, or use,
perhaps, "xtyped" rather than "geometric".

More importantly, however, my point is that it's really
general-purpose, user-visible VOTable libraries that need to support
xtypes and that have to have a defined behaviour in the view of
arrays of xtyped things to give a useful user experience.

In TAP services, that's far less of a concern.  Once there is array
support, xtyped columns will even survive an upload-download cycle
since they have perfectly valid types.  Of course, you perhaps
couldn't use special functions (e.g., contains of geometry, or future
timestamp functions, or whatever) on array elements.  

But then a client, even if it knew that a service can't do
CONTAINS(arr1[3], arr2[4]), could only raise an error (and that only
if it were really smart and had a very good idea of what's going on
in the query).  That error can just as well come from the server, I'd
say, and that's preferable if it saves us features.

Or am I missing something?

         -- Markus