<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks Markus.</div><div class=""><br class=""></div><div class="">I tried your TAP with the query you provided and found that</div><div class="">- your FIELD declaration contains: datatype=“float” arraysize=“*”</div><div class="">- votlint is happy with your returned votable</div><div class=""><br class=""></div><div class="">In my case instead:</div><div class="">- the FIELD has no arraysize and datatype=“double"</div><div class="">- votlint complains about it:</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">ERROR (l.159, c.43): Bad double string '123.269560 -34.578040'</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><br class=""></div><div class="">Given that I think we are both using Gregory’s library,</div><div class="">I wonder how you manage to get the arraysize into your votable…</div><div class="">In my votable only the “char” fields have gotten an arraysize=“*”</div><div class="">all other fields have no arraysize.</div><div class=""><br class=""></div><div class="">What is that I’m doing wrong? Maybe Gregory can tell me...</div><div class=""><br class=""></div><div class="">Many thanks,</div><div class="">Alberto </div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 01 Jun 2017, at 13:37, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Pat,<br class=""><br class="">On Wed, May 31, 2017 at 10:54:10AM -0700, Patrick Dowler wrote:<br class=""><blockquote type="cite" class="">I agree with the goal of supporting array-typed columns, I think 1-d<br class="">arrays are OK now, and I think this is within the realm of the TAP-1.1<br class="">update. It would make TAPType in VODataService obsolete since we could<br class="">just use VOTableType.<br class=""></blockquote><br class="">I'm all for that.<br class=""><br class=""><blockquote type="cite" class="">And I think this is actually a pretty small change and I'm almost<br class="">there in my prototype.<br class=""><br class="">Thoughts?<br class=""></blockquote><br class="">But then why not just take over the VOTable type system (or at least<br class="">arraysize) to TAP_SCHEMA, too? I'm noticing just now, but if<br class="">something in the vicinity of the VO is called arraysize, as an<br class="">implementor I'd be somewhat sore if it contained something different<br class="">than what is in VOTable's arraysize syntax (I'd be ok with dropping the<br class="">number-plus-star feature, like arraysize="7*").<br class=""><br class="">It does all we can possibly need at this point, and since dealing<br class="">with it is part of VOTable, people already have code to deal with<br class="">strings like these.<br class=""><br class="">For 1.1, I don't think we can switch datatype to VOTable types to<br class="">complete the transition (or can we?). But arraysize is new anyway,<br class="">and I can't see many reasons to keep the semantics of 1.0 size for<br class="">it.<br class=""><br class="">Oh, and:<br class=""><br class=""><blockquote type="cite" class="">On 31 May 2017 at 08:08, alberto micol <<a href="mailto:amicol.ivoa@googlemail.com" class="">amicol.ivoa@googlemail.com</a>> wrote:<br class=""><blockquote type="cite" class="">My use case regarding arraysize=???2" in TAP is here described.<br class=""><br class="">SSA 1.1 requires, in the VOTable output, a single field for the spatial<br class="">location,<br class="">expressed as:<br class=""><br class=""><FIELD ID="SpatialLocation" name="SpatialLocation" datatype=???double"<br class="">ucd="pos.eq" utype="ssa:Char.SpatialAxis.Coverage.Location.Value"<br class="">arraysize="2" unit=???deg???><br class=""><br class="">At ESO we are implementing SSA on top of TAP.<br class=""><br class="">I therefore created the spatial location column in the TAP_SCHEMA.columns<br class="">table declaring size=2,<br class="">but TAP does not translate this information into the (naively) expected<br class="">arraysize=???2???,<br class="">for the reasons that Gregory explained.<br class=""><br class="">Hence, we are stack with the development of the ESO SSAP...<br class="">unless some smart DAL person comes up with a solution!<br class=""></blockquote></blockquote><br class="">I'd say don't worry *too* much about that. At the GAVO data cetner,<br class="">we've been publishing tables with arrays for ages, and the fact that<br class="">we've been lying a bit about the TAP_SCHEMA metadata hasn't bothered<br class="">anyone (we have size NULL for them for var-size arrays, and we've<br class="">been abusing size for array length otherwise). If you don't believe<br class="">me, run<br class=""><br class="">select top 1 wcs_refpixel from lsw.plates<br class=""><br class="">on <a href="http://dc.zah.uni-heidelberg.de/tap" class="">http://dc.zah.uni-heidelberg.de/tap</a>. I'd be surprised if you<br class="">found a TAP client that wouldn't simply do the right thing (provided<br class="">they support arrays in VOTable cells at all).<br class=""><br class="">For SSA, incidentally, the situation is a bit different, because<br class="">conceptually what ssa_location is is a (spherical) point. You can<br class="">inspect the table flashheros.data (which is an SSA table) on our TAP<br class="">service to see what we do. Admittedly, that's not terribly<br class="">attractive because I doubt many clients do something sensible with<br class="">STC-S specs.<br class=""><br class="">With TAP 1.1, that's going to improve (the POINT xtype); so, that's<br class="">what I'd put into my VOTable if I wrote new code now:<br class=""><br class=""><FIELD datatype="float" arraysize="2" xtype="POINT".../><br class=""><br class="">-- clients will be happy with this for now, and a correct<br class="">TAP_SCHEMA/VODataService representation can follow when TAP 1.1 is<br class="">finalized.<br class=""><br class=""> -- Markus<br class=""></div></div></blockquote></div><br class=""></body></html>