WD-DALI-1.1

[Patrick Dowler]

I agree with "only specify what you've tried" but we already do
serialise polymorphic regions in TAP-1.0 (as well as SIA-2.0 and now
SODA-2.0) and this simply defines that serialisation via an xtype.
Now, I certainly would prefer if everyone stopped doing that and used
xtype="polygon" in their TAP services but not everyone will change and
clients will have to tolerate both for some time; this just gives
clients a single place to find DAL xtypes.

Defining an  xtype only defines a serialisation of structured value
and really only for use in VOTable and it is just ratifying current
use.


my 2c,

Pat

On 8 September 2016 at 00:53, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Dear DAL,
>
> On Wed, Sep 07, 2016 at 10:41:15AM -0700, Patrick Dowler wrote:
>> On  a somewhat more speculative nature, I have added a subsection that
>> defines the polymorphic "region" xtype. There is not yet consensus on
>> whether we should do this, but the values described show up in
>> SIA-2.0, SODA-1.0, and is essentially what we also use in TAP-1.0
>> (region columns sans additional metadata in the value)*.
>>
>> The diff so you can see what this might look like:
>>
>> https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3530&r2=3531
>
> Hm -- I'm not wild about this.  If I understood Alex' remark of a few
> months ago correctly, the point of Region would be to serve as an
> algebraic closure for geometries, i.e., the type that lets you apply
> a to-be-specified class of operators (union, intersection?,
> difference?  negation?) to its domain without ever leaving the
> domain.
>
> This, I believe, makes a lot of sense, in particular for ADQL when
> we define such operators (which we currently don't, but we may want
> to).
>
> Unfortunately, Region as proposed in rev. 3531 wouldn't work for that
> purpose, as it can only represent points, circles, ranges, and
> polygons.
>
> Now, I don't see there's a pressing use case for defining Region.
> According to my old mantra of "only specify what you've tried" I'd
> say let's defer it.
>
> As a hint on why I'd not like to see this put into stone now, here's
> *my* speculation, based on what I hope to have in the Registry: At
> least in implementation, the answer to the question of Region will
> have a lot to do with MOCs (which can actually represent arbitrary
> geometries as long as you're not sweating precision too much).
>
> I might be wrong, but I think we'll regret specifying something else
> without dire need right now.
>
>          -- Markus



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada