SCS-1.1 internal draft available

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue Jul 18 11:06:00 CEST 2017


Hi Walter,

On Mon, Jul 17, 2017 at 09:53:36AM -0700, Walter Landry wrote:
> Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> > Oh, SCS is painful in so many minor ways that cleaning it up to the
> > extent that's possible without breaking clients is absolutely
> > worthwhile.  Also, you can of course already use UCD1+ for everything
> > but the identifier and the main position, and most services do that.
> 
> I am confused.  Allowing VOTable > 1.0 will break old clients, and
> that is already in the proposed spec.  Is the update allowed to break
> old clients or not?

I propose to take a pragmatic stance there; while strictly speaking
it is conceivable that a really ancient client with an overzealous
VOTable library will break, in practice I'm not aware of a VOTable
parser still in use that isn't "robust" in the sense they're generous
with XML namespaces and unknown elements.

So, I'd contend that no SCS client in use will break with the update.
There may still be a few around that can't deal with BINARY, but
they're already broken in that. Still. along these considerations we
should make clear in SCS 1.1 that BINARY2 is only to be returned if
explicitly requested using RESPONSEFORMAT).

If, however, it turns out the contention that no actual clients break
is wrong, then yes, I'd say we should go straight to SCS 2, in which
case we'd be free to clean up the UCD act.

When the first 1.1 services come around, I think we'll see whether or
not I'm right.

        -- Markus

PS: I'll use this opportunity to again point to the XML schema
versioning policies RFC,
http://wiki.ivoa.net/twiki/bin/view/IVOA/XMLVersRFC -- it is designed
to make this kind of thing a lot less painless in the future and can
still do with a bit more of public review even at this point.


More information about the dal mailing list