pdowler
commented
3 years ago adql:REGION is not a standard; multipolygon is the simplest subset that supports the use cases that were brought forward and discussed... the purpose is to standardise enough to stop needing and using adql:REGION. No one had a reason to try to support something more general so we stopped at simple.
multipolygon is intended to make adql:REGION obsolete so arguing that we don't need it because we have adql:REGION doesn't make sense.
We can debate the serialisation format; the arbitrary separator(s) in a 1-D array is the way to do it with current VOTable. If VOTable had a more flexible mechanism for 2-D arrays (see https://github.com/ivoa-std/VOTable/issues/25) that we could use for numeric then we would be using it (see https://github.com/ivoa-std/VOTable/issues/25) and if adding such a thing had any traction we would have to consider waiting to see how it was going to work. TBD
msdemlei
I still don't see a convincing advantage in having multipolygon when there is adql:REGION that also can represent multiple polygons. Having two ways to express the same thing is never good (though, admittedly, sometimes still preferable), and I'd need to see a convincing argument for why we need to accept this uglyness here (for instance: Here's a VOTable parser that can't do adql:REGION but can to multipolygon).
On the other hand, there is the standing issue of having arrays of variable-length things in VOTable. A fix for that is something that would help many applications (Registry, for instance, yearns for arrays of variable-length strings) that are really clumsy otherwise (cf. ADQL's ivo_string_agg user-defined functions).
So, if the multipolygons came in as a side effect of fixing the long-standing x-array problem, I'd be a lot more relaxed about introducing a second representation for multiple polygons; at least it wouldn't be yet another ad-hoc special case but would fit into general VOTable handling.