Simple Cone Search - starting a revision

[Marco Molinaro]

Dear DAL,
I've started to modify the SCS-1.03 to prepare
an internal WD for revision 1.1 following what
has been discussed in Shanghai at DAL session 1
(see "Refreshing SCS specification" at
http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2017-DAL)

In order to encourage discussion, I prepared a
http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Next
wiki page to reflect the topics to discuss, so that
discussion can take place while I prepare the first draft.

Anyway, directly from the first steps in modifying the doc,
I have already a few points to highlight here for discussion,
for all the involved parties.

1 - single INFO element in service validation
==================================
This was raised in the plenary OPS session 2 in Shanghai.
(see EURO-VO registry report at
http://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2017-Ops)
and refers to the sentence in SCS that currently states:

>>In the case of error, the service MUST respond with a
VOTable that contains a single PARAM element or a
single INFO element with name="Error"...<<

where there's ambiguity in the interpretation of single,
meaning -single one having the name="Error"- or
-single INFO element- at all.

This makes most cone searches fail validation.
Suggestion has been made to issue an Erratum for this.
Even if it's not explicitly a SCS-1.1 topic, it will help in
the revision process.

2 - allowing POSTing to cone search services
===================================
GET or POST for synchronous resources is the same
for DALI, and letting POST by available to SCS seems
a direct thing.

However, SCS-1.03 has base URL defined as
http://<server-address>/<path>?[<extra-GET-arg>&[...]]

thus, in case of POST, where do we set the <extra-GET-args>?

a - leave them as GET args and have a mixed GET/POST
b - ask, supporting POST, also the extra go to POST data
c - promote path-params directly in 1.1, removing the
possibility to have extra-GET-args in SCS base URL

a) seems straightforward, even if not so neat
b) requires extra work for clients to adapt (apart from server)
c) breaks a bit current spec, even if we leave current
base URL as allowed and only discourage it

3 - the capabilities endpoint
=====================
Trying to bring SCS in a more DALI shape, there are two
VOSI resources that are required: capabilities and availability.
I leave out the second one at present, and focus only on the
capabilities.
Again, without the <extra-GET-args> adding a should to the
specification would be easy, but how to deal without removing
the extra args (or, better, without moving them from being
attached to the base URL)?

Technically, attaching the <extra-GET-args> to /capabilities after
the server/path/ base can be done, but I don't know if it's a good
idea, even if considering a cone search (multi-)service serving
various catalogues that use the extra-GET-args to distinguish
among them.

Every thought, comment, suggestion is welcome on all the three
above, the wiki page topics or other things you feel are needed
for a new version of the SCS.

I'll get anyway back to you when the first SCS-1.1 internal draft is
ready.

Cheers,
    Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170711/ddc3b757/attachment.html>