WD-DALI-1.1

[Patrick Dowler]

The reason for including it is that it helps define the POS parameter
in SIA and SODA. Because params for SODA are normally described in
service descriptors, not having xtype="region" looks like a hole in
that spec.

Then  there is the TAP practice of having output columns describd with
an xtype. We already had plenty of confusion about what to put there
and existing practice would be covered by including this now (+/- the
use of adql: prefix and the case so that is now clear).

Those are my two motivations for defining xtype='region" in DALI-1.1
(which we need for SODA-1.0 anyway due to other xtypes introduced):
consistent use.

Pat


On 9 September 2016 at 01:13, Marco Molinaro <molinaro at oats.inaf.it> wrote:
> 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



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