TAP VOSI Information
Tom McGlynn
Thomas.A.McGlynn at nasa.gov
Tue Nov 24 10:21:54 PST 2009
You're right. I was confusing it with the some of the other more
specialized binary types like IMAGE or RAW and should have checked.
Below I am dubious though of associating VARBINARY and such xtypes with
an ADQL name space. ADQL knows nothing of these types (e.g., I don't
think VARBINARY shows up in a text search of the ADQL document). I
think a TAP (or SQL namespace) would be more appropriate.
Tom
Patrick Dowler wrote:
> On Tuesday 24 November 2009 05:20:07 Tom McGlynn wrote:
>> The current TAP specification is a bit unclear about this. The current
>> draft doesn't mention VARBINARY data at all.
>
> The TAP spec very explicitly mentioned VARBINARY and BLOB and how they are to
> be described.
>
> A column of type VARBINARY is mapped as Mark said:
>
> <FIELD datatype="unsignedByte" arraysize="*" .... />
>
> and it would be correct to include xtype="adql:VARBINARY" as well. The service
> could put something more specific for arraysize. Since the datatype and
> arraysize are sufficient, the xtype is redundant in this case and could in
> principle be used for something else; we debated this extensively and I did
> bring up the idea of embedding a small image in the results but that idea
> never got any traction...
>
> The only fields where xtype is required to be an adql-specific value are
> TIMESTAMP, POINT, REGION. For those, datatype="char" and arraysize="*" but
> they are not simply strings. What needs to be clear in the spec is that these
> are the only cases where xtype is mandated. In other cases, both uploads and
> results are sensible using the other field attributes.
>
> So, right now the TAP spec does not specify how to deal with an embedded
> binary image; I think we should leave that to 1.x but I also think people
> could experiment with using xtype without being non-compliant with the TAP 1.0
> spec.
>
More information about the dal
mailing list