Simple Cone Search 1.1 - (new) internal WD

[Markus Demleitner]

Hi DAL,

On Mon, Oct 09, 2017 at 02:29:51PM -0700, Walter Landry wrote:
> Marco Molinaro <molinaro at oats.inaf.it> wrote:
> > I just fixed a couple of sentences and typos in the internal WD built
> > in July and I attach it here for you.
> > 
> > Discussion points are still the same.
> > I would say that
> > 1 - ReST vs. query_param access_url
> > 2 - RESOURCE type="results" and multiple RESOURCEs
> > 3 - minor vs. major revision
> 
> Minor vs Major looks like you have already decided this.  The working
> draft that you sent no longer mandates VOTable 1.0 or 1.1.  That
> change alone will break existing clients.  So if we are actually
> serious about semantic versioning, this should be SCS 2.0, not 1.1.

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.

It's true that the schema versioning note isn't even endorsed yet,
and of course hasn't been in force ten years ago.  But the VOTable
libraries I've encountered have essentially done just what it
proposes for a long while.

Why am I opposed to a major version step?  Well, it's going to break
all clients needlessly -- even though they would continue to work,
they, at the very least, won't discover the services any more,
probably worse.  That's a bad thing to happen for the most widespread
protocol in the VO.

The point of 1.1 to me really is to remove unnecessary pain from SCS,
not to build something new.  If, on the other hand, we were to go for
2.0, I'd say we should fix a lot more, in particular as regards
machine consumability.  Right now, joining results from more than one
SCS service is *very* hard.  Making this easier, presumably based on
the Source DM, would be worth breaking the existing infrastructure.
But to me that's an entirely different project on an entirely
different time scale.

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

That's a price I'm totally willing to pay for not having to support
two different SCS versions for an unforseeable time, with another
major update (when we have a Source DM) desirable in some forseeable
future.


          -- Markus