<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="">My use case regarding arraysize=“2" in TAP is here described.</div><div class=""><br class=""></div><div class="">SSA 1.1 requires, in the VOTable output, a single field for the spatial location,</div><div class="">expressed as:</div><div class=""><p class="MsoPlainText"><FIELD I<span style="font-size: 9pt;" class="">D="SpatialLocation" name="SpatialLocation" datatype=</span>“<span style="font-size: 9pt;" class="">double" ucd="pos.eq" utype="ssa:Char.SpatialAxis.Coverage.Location.Value" arraysize="2" unit=“deg</span>”<span style="font-size: 9pt;" class="">></span></p><p class="MsoPlainText">At ESO we are implementing SSA on top of TAP. </p></div><div class=""><span style="font-size: 9pt;" class="">I therefore created the spatial location column in the TAP_SCHEMA.columns table declaring size=2,</span></div><div class=""><span style="font-size: 9pt;" class="">but TAP does not translate this information into the (naively) expected arraysize=</span>“<span style="font-size: 9pt;" class="">2</span>”,</div><div class="">for the reasons that Gregory explained.</div><div class=""><br class=""></div><div class="">Hence, we are stack with the development of the ESO SSAP...</div><div class="">unless some smart DAL person comes up with a solution!</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><blockquote type="cite" class=""><div class="">On 31 May 2017, at 16:34, Grégory Mantelet <<a href="mailto:gmantele@ari.uni-heidelberg.de" class="">gmantele@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Dear DAL members,<br class=""><br class="">Sorry to come back again with the "array" topic, but I have more and more requests for having arrays in my TAP-Library (and, personally, I will also need that quite soon) but I do not know how to proceed. Even though nothing formally forbids it, there is actually no possibility to declare arrays in TAP_SCHEMA...so in a way it is kind of preventing/forbidding the usage of arrays if nobody can really know that a column is an array.<br class=""><br class="">I have searched in TAP-1.0, the coming TAP-1.1 and in VODataService in the hope to find something leading us toward a solution. Here is what I found and my related questions:<br class=""><br class=""><br class="">## In TAP 1.0<br class=""><br class="">In REC-TAP-1.0, two columns of TAP_SCHEMA.columns let specify the type of a published column, defined as follows:<br class=""> - datatype - "ADQL datatype as in section 2.5"<br class=""> - size - "length of variable length datatypes"<br class=""><br class="">With the following additional description:<br class=""><br class=""> "Data types and how they map to VOTable datatypes are described in section 2.5<br class=""> above. The “size” gives the length of variable length datatypes, for example<br class=""> varchar(256); this size does not map to the VOTable arraysize attribute when the<br class=""> latter specifies the size and shape of a multi-dimensional array."<br class=""><br class="">As written here, "size" does not aim to tell whether the value is a scalar or an array ; it is just the N in CHAR(N), VARCHAR(N), BINARY(N) and VARBINARY(N).<br class=""><br class=""><br class="">## In TAP 1.1<br class=""><br class="">In WD-TAP-1.1, in addition of the above two columns, "arraysize" has been added. So the datatype descriptive columns are now:<br class=""> - datatype - ?? (the description disappeared in this WD)<br class=""> - "size" - ?? (idem)<br class=""> - arraysize - ?? (idem)<br class=""><br class="">With the following additional description:<br class=""><br class=""> "The arraysize column gives the length of variable length datatypes, for<br class=""> example varchar(256); this arraysize does not map exactly to the VOTable<br class=""> arraysize attribute because the latter can specify the size and shape of a<br class=""> multi-dimensional array as well as the variable size.<br class=""> [...]<br class=""> In the next major version of TAP, the "size" column<br class=""> will be removed."<br class=""><br class="">So, even in TAP-1.1 there will be no way to add information about arrays.<br class=""><br class="">==> Furthermore, though I can understand the reason why "size" should be deprecated (collision with an ADQL reserved keyword....by the way, will we still have reserved keywords with the PEG grammar for ADQL?), is it really a good idea to call a column "arraysize" if it is not about an array?<br class=""><br class="">==> And then, why having the same name as in VOTable if it does not do the same?<br class=""><br class=""><br class="">## In VODataService 1.1<br class=""><br class="">In REC-VODataService-1.1 (used to describe published columns in TAP's entry point '/tables'), the datatype of a column can be expressed using two types of type:<br class=""> - VOTableType (e.g. <dataType xsi:type="vs:VOTableType" arraysize="*"> char </dataType>)<br class=""> - TAPType (e.g. <dataType xsi:type="vs:TAPType" size="8" > CHAR </dataType>)<br class=""><br class="">According to the XML schema of VODataService-1.1, TAPType is the only one that can have a "size" attribute defined as described in TAP 1.0 (i.e. "The length of the variable-length data type."). Ok, that makes sense since it is only something coming from TAP.<br class=""><br class="">==> By the way, is it also planned to deprecate "size" from VODataService as in TAP-1.1?<br class=""><br class="">However, both VOTableType and TAPType can have an "arraysize" attribute defined as described in VOTable (i.e. an ArrayShape = " An expression of a the shape of a multi-dimensional array of the form LxNxM... where each value between gives the integer length of the array along a dimension. An asterisk (*) as the last dimension of the shape indicates that the length of the last axis is variable or undetermined.").<br class=""><br class="">So, here, we have a completely different definition of "arraysize" than in WD-TAP-1.1.<br class=""><br class="">==> Is there a mistake here? If yes, which standard has to be updated: VODataService or TAP? And in which direction?<br class=""><br class=""><br class="">## To conclude,<br class=""><br class="">==> considering these three documents and knowing that TAP-1.1 is still in WD, how can we declare arrays in TAP_SCHEMA (and /tables result)?<br class=""><br class="">I personally like to have something consistent and so I would go for re-defining the new column "arraysize" as in VODataService and VOTable.<br class=""><br class="">==> But does it make sense to combine this VOTable piece of information with the datatypes of TAP (i.e. the so-called TAPType like VARCHAR, BIGINT, BLOB, ...)? If not, what other alternative(s) do we have?<br class=""><br class="">Cheers,<br class="">Grégory<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>