*ConeSearch: Status & Discussion
*(Thursday May 7 - 13:30 UTC)
Participants: 61

*Quick summary
refactored from intro slides available here:
    https://wiki.ivoa.net/internal/IVOA/InterOpMay2020DAL/MolinaroNebot_IVOA2020A_ConeSearch.pdf

ConeSearch is under revision but we need to take some decisions to move on.
	* how to foster take-up?
	* will it be a 1.x or a 2.0 revision?
		* how do we deal in case of major transition?
		* how do we deal with deprecation?
		* ReST vs query-param allowing...
	* how to deal with flavoring resources in registry?
	* MarkT: How does a client know whether they're talking to a 1.0 or 1.x/2.0 service? And whether TIME queries are meaningfully supported?  
		* version attribute in the capability, eg version="1.1" (even is standardID does not change)
		* Also, DALI recommends including an INFO with the standardID in the VOTable... to describe the service that created it. Convey version here?
	* impact of "caproles"?

Divide the changes into 1.1 and 2.0 and plan both?

These depend on a set of updates, deprecations, additions.

Update:
	* RA & Dec in float also
	* MAXREC
	* RESPONSEFORMAT
	* VOTable-1.0+/1.4+
		* JD: As a data provider, we would prefer to only manage a single version of VOTable for all services
		* MT: Any VOTable 1.x version should not break clients and is compliant with the current spec
		* Gregory: §2.2 states VOTable 1.0 or 1.1 allowed in the REC 1.03
		* MT: oh yes - so I was wrong, VOTable 1.2+  is not compliant with current spec.  Sorry.  My guess is that in practice returning later version VOTables will not break existing clients, but that's not the same thing.
		* MD: Would like to have a small revision that allows newer VOTable formats, reflecting what many providers already do
		* Xiuqin Wu: NED does not have ConeSearch service. My original thought was to support it by calling TAP service. If the minor chnage will support VOTable 1.2+, we could support it fairly easily.
	* RESOURCE/TABLE type & number
	* [Pat] Is this one of the things to fix in minor (1.1)? iirc type attr is mandatory in later VOTable
	* 1.03-Erratum-1

Deprecate: (works for 1.x choice)
	* error response
	* SR=0
	* query <extra-args> <- what with VOSI endpoints ->
		* Gregory: IRSA uses an extra table param to allow table selection. Removing extra args support will break this, and thus be a big impact on providers
		* [Pat] Since this is nominally a way to have one service in front of multiple tables, how about describing that by formalising the "target table" input param? iirc this was tossed around for TAP + PQL...
	* UCD <- not really a deprecation ->

Additions:
	* TIME param- EPOCH param
	* AllSky "SR"- ST-MOC filtering
	* response field for time of observation
	* HTTP-POST <- what about extra-args ->
	* ReST vs query-param allowing
    
*Questions:
*(write your "Name: my question?" in this list)
	1. [Pat] Can/should SCS-next use the same core params as SIAv2 and SODA: POS, BAND, TIME ?
		2. [Ada]: I was thinking about that too I just don;t know the implications 
		2. Expect this is SCS-2.0
	1. [Pat] Is the output content directly dependent on (waiting for) a Source DM? Or should output be in "local" or "native" (field names) and (later) annotated with Source DM (once we have the model and VO-DML annotation)?
		2. [Laurent] I vote for the SourceDM option .
		2. This would seem like SCS-2.0 to specify standard output
	1. (gilles)..do ou plan to allow a cone search with time constraint without position ? (need special time indexation)
	1. Markus: My main motivation is to stop forcing people to use ancient VOTable when probably all non-ancient clients don't need it.  Can't we do a minimal update that basically just solves this?
	1. Markus: We could still open up for a few new features by saying: "if you're a client, try a capabilities sibling and if you find it, use newer features"
	1. (gilles) What about time precision? is it possible to add error resulting from time conversion (i saw that UTC was choosen for output).--> UTC is for input not output
	1. Tom asked if we could have a TIME parameter without further spec because SCS lets you have extra parameters. Markus: Sure, we can.  The trick is to make that discoverable.  Clients can already see it in the Registry (the interface element has parameters), but nobody wants too look this kind of thing up there.  On the service, we could make a convention that clients can pass in MAXREC=0 (only).  On old (1.1303) services, that'll return an error, and clients know they shouldn't look at the result.  On new-style services, this would return SIAP1-style PARAMs describing the input parameters.
   [Gregory D-F] Markus, when you say "1.13" clients would return an error on 'REQUEST=getCapabilities', did you mean old, 1.03-conformant clients, or did you mean "1.13" as the name of a new version of the standard?  Markus: Sorry, I meant 1.03.  1.13 was just a fluke in my memory.  If the former, I guess the argument is that if you make a request without RA, DEC, and SR, you'll get an error, regardless of whether there's a REQUEST parameter or not (Markus: or, in my revised proposal, MAXREC)?  Exactly: RA, DEC are missing, hence error.
   [Gregory] I like the MAXREC version of the proposal very much.
8. [MarkT] How to tell up front whether a service supports the TIME queries?
	Markus says in principle services can declare optional parameters in the registry (DaCHS does, others may not so much?).  That's probably OK for me, if they do.

9. [Gregory D-F] I’d like to put on the table for future revisions some way of supporting multi-center queries.
	... TAP?  This has come up before, and the response has generally been, it's not really Simple Cone Search if there's lots of points, and you should use TAP which is designed to be much more flexible.  But, I'm not saying that's the last word on the question.  CDS XMatch for instance is a very useful service with effectively this functionality, but without conforming to any standard.
	The appealing possibility - from the perspective of a client developer - is to figure out how to use DataLink to enable going from a set of rows in a result table to a multi-object query, driven by service-descriptor information in the original response, on a related catalog.  This is much easier when the "downstream" service has structured query parameters vs. when the downstream service is TAP and needs ADQL to be written.

10. We should think about what could go wrong. 
What if .... a researcher is looking at transients, and wants to find all observations that happened on a specific day. Based on the latest specification, they construct a coneSearch query with very broad spatial constraint and a very specific time constraint. Then they send it to all the conesearch services they can find registered in the registry. They are expecting to get a small list of observations made within a specific time period, but some legacy services may interpret the query as an all sky query and return everything in their database. This is not what the user intended. How can we mitigate the unexpected side effects of our changes ?