Simple Cone Search 1.1 - (new) internal WD

[Walter Landry]

Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> Again, I don't believe there's a single SCS client in actual use that
> would not deal perfectly well with VOTables > 1.1 (of course, I could
> be wrong, but I'd have to see one[1]).  So, in practice I'd argue
> we're fine with SCS 1.1 *and* allowing VOTable 1.x.  
> 
> The underlying theory, by the way, is provided by the schema
> versioning note, where it says clients are supposed to ignore
> elements they don't understand.

I wrote one that never supported BINARY and, for some time, did not
support BINARY2.  Yet it was still useful.  BINARY2 is not just
ignoring new elements.  So as a point of order, we need to bump the
version number.  We do not have to make any other incompatible
changes, but lets not fool ourselves that all 1.0 clients can get
useful information from a "1.1" server.

>> > are the main ones, while
>> > 4 - trying or not to use UCD1+
>> 
>> Pretty please?  We allow access to our tables via a number of
>> protocols (SIA2, SSA, SCS, TAP).  I really, really, really do not want
>> to maintain different UCD's for each protocol.
> 
> True, that's a wart, but changing the UCDs *would* actually break
> clients.  Also, on the server side it's not *that* much of an issue.
> In DaCHS, it's about 20 lines of relatively benign code -- essentially:
> 
> 		ucdCasts = {
> 			"meta.id;meta.main": {"ucd": "ID_MAIN", "datatype": "char", 
> 				"arraysize": "*"},
> 			"pos.eq.ra;meta.main": {"ucd": "POS_EQ_RA_MAIN", 
> 				"datatype": "double"},
> 			"pos.eq.dec;meta.main": {"ucd": "POS_EQ_DEC_MAIN", 
> 				"datatype": "double"},
> 		}
> 
> (and a bit of support code in the serialiser that's required for
> SIAP, too)-- and with SCS 1.1, the datatype cast could go away.

I would like to provide more than 3 UCD's.  They are kind of useful.

Cheers,
Walter Landry