<div dir="ltr"><div><div>The WD-DALI-1.1 (diffs: <a href="https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3117&r2=3135">https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3117&r2=3135</a>) defines xtypes for timestamp, interval, point, circle, and polygon. Timestamps are defined as char and the others are defined as arrays of double and values do not include the shape.<br><br><br>There is a TODO/question about whether we should specify the coordinate "range" construct and/or the STC "box" concept... the only real use cases are that they can be more convenient than polygon but they don't enable any new functionality.<br><br></div>I agree that we do not need xtypes for identifiers (at most, you might want to say that the char* value is a URI and can be parsed as such) and certainly not for polarization states. That's more like an enum or a vocabulary... <br><br></div>Given that DALI-1.1 defines the needed xtypes (and it is in DALI because we want consistency across multiple services) I agree that SODA doesn't need to define any xtypes at this time.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 2:43 AM, Mark Taylor <span dir="ltr"><<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Markus and DAL.<br>
<span class=""><br>
On Wed, 20 Jan 2016, Markus Demleitner wrote:<br>
<br>
> In order to get on with my list of gripes, here's my second one. In<br>
> two sentences:<br>
><br>
> SODA should not define any xtypes. That's DALI turf.<br>
><br>
> The concrete consequence: All specifications of xtypes except the<br>
> interval should go from SODA standard parameters.<br>
<br>
</span>I am somewhat in agreement, but I wouldn't go quite as far as Markus.<br>
<span class=""><br>
> The reason simply is: They serve no purpose. In the case of POS, not<br>
> only do they serve no purpose, they're actually damaging.<br>
><br>
> Here's the background on xtypes: xtype is a VOTable attribute to<br>
> FIELDs and PARAMs introduced in (I think) 1.2 because there was<br>
> resistance to extending the VOTable type system to some types that<br>
> were found desirable when delivering database tables, in particular<br>
> timestamps and geometry values.<br>
><br>
> Retrospectively, I think it was a mistake to do this, because in the<br>
> end, it just confuses VOTable's type system, and VOTable<br>
> implementations will have to do something with all the types we're<br>
> defining anyway or we have a major interoperability problem on our<br>
> hands. It'd have been much better to be honest about the feature<br>
> creep and extend the type system in VOTable itself.<br>
<br>
</span>I disagree with this. The point about having xtypes hanging off<br>
an existing datatype is exactly that VOTable implementations<br>
do *not* have to do something xtype-specific with them.<br>
Consider a value described thus:<br>
<br>
<PARAM datatype="char" arraysize="19" xtype="iso8601"<br>
value="2016-01-20T10:08:25"><br>
<br>
A general-purpose VOTable processing library or application<br>
can perfectly well present the values to downstream software or<br>
to the user as a string. Time-aware software meanwhile can work<br>
out how to convert it to an MJD or whatever. Software that sees<br>
an xtype it doesn't recognise can and should just ignore it,<br>
and treat the data just as it would if it had no xtype<br>
(though propagate the xtype value downstream where appropriate).<br>
It's somewhat like a UCD or Utype in this respect, but it's<br>
orthogonal to that, because it's to do with how to map<br>
VOTable-friendly primitive datatypes to some other value domain,<br>
rather than being concerned with semantics as such. Doing it<br>
like this protects us from having to constantly update the<br>
VOTable standard, and hence general-purpose VOTable processing<br>
software, every time we think of a new value domain that we<br>
need to transport. FITS has managed for however many decades<br>
it is without having to update its type system, and the VOTable<br>
type system is based on that (I consider this last point a<br>
good argument, but if you're a FITS-hater, kindly pretend<br>
I didn't say it).<br>
<span class=""><br>
> While that ship has sailed, it's important to limit the damage: let's<br>
> at least be very cautious when introducing new xtypes lest we make<br>
> VOTable unimplementable. There should be exactly one place in which<br>
> xtypes are defined. It seems that one place is DALI.<br>
<br>
</span>I think that using DALI as the standard place to look for well-known<br>
xtypes is an excellent idea, and I look forward to seeing the<br>
relevant draft. However, I don't agree on an embargo on non-DALI<br>
xtype definitions. Other standards, or even projects or individuals,<br>
can use their own less-well-known or even private xtypes, but may<br>
not be able to rely on general purpose software to do anything<br>
clever when they encouter them. Such less-well-known xtypes<br>
do not "make VOTable unimplementable" or otherwise impact<br>
on the implementability of VOTable itself.<br>
<br>
Having said that:<br>
<span class=""><br>
> All other xtypes are gratuitous and should go. This concerns<br>
><br>
> * ID's xtype="ivoident"<br>
> * POL's xtype="Stokes" (or "stokes"; the draft proposes both)<br>
><br>
> These serve no purpose I can discern. What would clients do with<br>
> them? Instead, they just pose traps into which services will fall<br>
> when they're validated -- services that otherwise perfectly work.<br>
<br>
</span>I basically agree with this as far as most of the xtypes in the<br>
SODA WD go. Unless there is some obvious work for them to do,<br>
I don't think it's a good idea to proliferate new xtypes.<br>
<span class=""><br>
> They'll also be points of confusion when implementors ask themselves<br>
> what they should possibly to with these xtypes. I solemnly proclaim<br>
> that I won't be the one to stand up on the mailing lists and explain,<br>
> they're not supposed to do anything to VO newcomers.<br>
<br>
</span>(Parenthetically: I have no objection to doing that standing-up-<br>
and-explaining. For the reasons I've outlined above I think it's<br>
defensible, and I doubt if VO newcomers who've waded through the<br>
UCDs and Utypes will be very upset to find another attribute they<br>
are allowed to ignore.)<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>