WD-DALI-1.1

[Marco Molinaro]

Hi,
I'm a bit hanging in the balance here because I'm too looking forward
for MOC representations and the impact they may have in interfaces
and because setting an xtype="region" may resolve into freezing
something that is currently used but may change in the future.

On the other side the goal of DALI is to normalize interface practises,
and xtypes falls into its duties.

Would it be really that bad to leave this out of REC for DALI-1.1?
It seems that if we start discussing this here right now we'll have to
wait quite long before having 1.1 in PR form, and this has some drawbacks
on the rec process for other specs too.

Cheers,
   Marco

2016-09-08 18:47 GMT+02:00 Patrick Dowler <pdowler.cadc at gmail.com>:
> 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