<div dir="ltr">Hi Markus, all,<br><div class="gmail_extra">if a type system (and inheritance) is in place, I'm not sure that it is a good idea </div><div class="gmail_extra">to mandate a single type system for a protocol.</div><div class="gmail_extra">I can agree on the not neat extension mechanism for data types we have in place.</div><div class="gmail_extra">Wouldn't it be preferable to have the type system cleaned up, rather than hacking </div><div class="gmail_extra">the behaviour at protocol level?</div><div class="gmail_extra"><br></div><div class="gmail_extra">In any case I wouldn't touch VOSI, it has (could have) a more general use </div><div class="gmail_extra">than for TAP only.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Beware, this is a quick reply, I didn't investigate what drawbacks can bring up</div><div class="gmail_extra">re-fitting the type systems out there.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"> Marco</div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-16 12:38 GMT+01:00 Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
While playing with a table that actually has a region-valued column<br>
(in case you're curious: antares10.data on ivo://org.gavo.dc/tap), I<br>
was horrified to see it is shown in TOPCAT's metadata browser as<br>
being of type char[*].<br>
<br>
The reason for that is that that's what I'm saying on the VOSI<br>
endpoint:<br>
<br>
<column><br>
<name>origin_est</name><br>
<description>A circle around the most likely position<br>
with ang_error radius (for convenient matching)</description><br>
<ucd>obs.field</ucd><br>
<dataType arraysize="*" xsi:type="vs:VOTableType">char</dataType><br>
<flag>nullable</flag><br>
</column><br>
<br>
Background: VODataService 1.1 defines several type systems --<br>
essentially, the inheritance tree looks like this:<br>
<br>
DataType<br>
|<br>
+--- SimpleDataType (integer, real, complex, boolean, char, string)<br>
|<br>
|<br>
+--- TableDataType<br>
|<br>
+--- TAPType<br>
|<br>
+--- VOTableType<br>
<br>
and VOTableType doesn't really contain the VOTable's xtype (we could<br>
probably hack it through extendedSchema and extendedType, but I'd<br>
rather wait how bad the xtype thing will really turn out).<br>
<br>
When writing DaCHS' VOSI interface, I figured that since I'm usually<br>
producing VOTables, writing my types as VOTableTypes would be the<br>
most sensible thing to do.<br>
<br>
Turns out it's not.<br>
<br>
Leaving aside my general skepticism towards stealthily expanding<br>
VOTable's type system with xtype, which I believe will keep causing<br>
lots of headache: I believe to keep clients and users sane, we should<br>
in TAP 1.1 (and perhaps VOSI 1.1) say that in the table metadata of<br>
TAP endpoints, services really-really-should use the vs:TAPType type<br>
system (which probably needs to be fixed soon to include CIRCLE and<br>
POLYGON), and announce that in the next major version, that will<br>
become a must.<br>
<br>
Thoughts?<br>
<br>
Cheers,<br>
<br>
Markus<br>
</blockquote></div><br></div></div>