WD-DALI-1.1

[François Bonnarel]

Dear all,

A little bit late about this.
Le 08/09/2016 18:47, Patrick Dowler a écrit :
> 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.
I fully agree with this. and support this change in DALI. May I cite one 
of our dear colleagues January 20Th 2016 ? He explained roles of xtypes 
like this  much better than I could do and I hope he will not be angry 
against me for citing him. ;-)

> The point about having xtypes hanging off
> an existing datatype is exactly that VOTable implementations
> do*not*  have to do something xtype-specific with them.
> Consider a value described thus:
>
>     <PARAM datatype="char" arraysize="19" xtype="iso8601"
>            value="2016-01-20T10:08:25">
>
> A general-purpose VOTable processing library or application
> can perfectly well present the values to downstream software or
> to the user as a string.  Time-aware software meanwhile can work
> out how to convert it to an MJD or whatever.  Software that sees
> an xtype it doesn't recognise can and should just ignore it,
> and treat the data just as it would if it had no xtype
> (though propagate the xtype value downstream where appropriate).
> It's somewhat like a UCD or Utype in this respect, but it's
> orthogonal to that, because it's to do with how to map
> VOTable-friendly primitive datatypes to some other value domain,
> rather than being concerned with semantics as such.  Doing it
> like this protects us from having to constantly update the
> VOTable standard, and hence general-purpose VOTable processing
> software, every time we think of a new value domain that we
> need to transport.  FITS has managed for however many decades
> it is without having to update its type system, and the VOTable
> type system is based on that (I consider this last point a
> good argument, but if you're a FITS-hater, kindly pretend
> I didn't say it).
>
>
> I think that using DALI as the standard place to look for well-known
> xtypes is an excellent idea, and I look forward to seeing the
> relevant draft.  However, I don't agree on an embargo on non-DALI
> xtype definitions.  Other standards, or even projects or individuals,
> can use their own less-well-known or even private xtypes, but may
> not be able to rely on general purpose software to do anything
> clever when they encouter them.  Such less-well-known xtypes
> do not "make VOTable unimplementable" or otherwise impact
> on the implementability of VOTable itself.
Cheers
François

PS: A beer or whatever drink in Trieste for the author and all people 
remembering who he was !!! Paid by the DAL chair !
>
>
> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160922/90b52d64/attachment.html>