<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Dear all, <br>
<br>
A little bit late about this.<br>
<div class="moz-cite-prefix">Le 08/09/2016 18:47, Patrick Dowler a
écrit :<br>
</div>
<blockquote
cite="mid:CAFK8nrqiEMFoHdVG_hDJWKAirwT_77qnMQZZMRX=Ku1ppcL0tA@mail.gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
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. <span class="moz-smiley-s3"><span>
;-) </span></span><br>
<br>
<blockquote type="cite">
<pre wrap="">The point about having xtypes hanging off
an existing datatype is exactly that VOTable implementations
do <b class="moz-txt-star"><span class="moz-txt-tag">*</span>not<span class="moz-txt-tag">*</span></b> 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).
</pre>
<pre wrap="">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.</pre>
</blockquote>
Cheers<br>
François<br>
<br>
PS: A beer or whatever drink in Trieste for the author and all
people remembering who he was !!! Paid by the DAL chair !<br>
<blockquote
cite="mid:CAFK8nrqiEMFoHdVG_hDJWKAirwT_77qnMQZZMRX=Ku1ppcL0tA@mail.gmail.com"
type="cite">
<pre wrap="">
my 2c,
Pat
On 8 September 2016 at 00:53, Markus Demleitner
<a class="moz-txt-link-rfc2396E" href="mailto:msdemlei@ari.uni-heidelberg.de"><msdemlei@ari.uni-heidelberg.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear DAL,
On Wed, Sep 07, 2016 at 10:41:15AM -0700, Patrick Dowler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3530&r2=3531">https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3530&r2=3531</a>
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>