Simple Cone Search 1.1 - (new) internal WD

[Markus Demleitner]

Hi Walter,

On Tue, Oct 10, 2017 at 09:23:28AM -0700, Walter Landry wrote:
> 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.

Hm -- it's not as easy as that.  Again: If we bump the major version
number, clients will have to support two different protocols instead
of one, and for a while services will want to offer both interfaces.
Introducing a new major version is a big thing, and we should only do
it if we have major benefits.

I'm not speaking against starting work on SCS 2.0 now, which can
bring all these benefits.  But that's altogether another matter than
just loosening the (IMHO misguided) requirement of SCS 1.0 to 
serve VOTable <=1.1.

As to your client that didn't do BINARY: Well, that wasn't a full SCS
client in the first place, as even with SCS 1.0 services were fully
entitled to return BINARY VOTables.  So, the update wouldn't break it
in the sense that it was already broken.

As to BINARY2, we could simply say (and that's actually the behaviour
of DaCHS):

  Services MUST NOT serve VOTables in BINARY2 serialisations unless
  the client explicitly requests it using a
  RESPONSEFORMAT=application/x-votable+xml;serialization=BINARY2
  request parameter.

> >> > 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.

You are free to give UCD 1+ ucds in all fields not required for SCS
-- that's common practice.  For instance (random SCS service picked):

http://vizier.u-strasbg.fr/viz-bin/votable/-A?-out.all&-source=J%2FApJ%2F798%2F54%2Ftable3&RA=0&DEC=10&SR=180

      -- Markus