# Astro-CC Tech Forum 1 - Simple Cone Search hack-a-thon session report *attendees: Alberto, Ilja, Marco, Mark T.,Markus, Tamara* The hack-a-thon went through the history of the 1.03 to 1.1 revision, with a recap of what currently is in the repository and the actions taken, plus a check on agreement/disagreement. The skeleton for the discussion used the DAL Running Meeting #21 notes (reported here below). Most of the already actions taken were agreed upon easily. Some missing action reviewed. Highlighted actions and discussion topics: - re-opened the issue for behaviour in responses to optional parameters - to clarify/structure the info/warning solution - take care of the ConeSearch -> DALI -> DataOrigin (PEN) reference chain - **discuss** meta.id;meta.main column unique behaviour in the basic ConeSearch model - clarify/explicit ConeSearch text - discuss with catalog/data providers - reach an **agreement** ========= # DAL Running Meeting #21 - Cone Search 1.1 **Date:** 4 September 2025, 1pm UTC **Participants:** Marco Molinaro (MM), Mark Taylor (MT), Gilles Landais (GL), Tess Jaffe (TJ), Grégory Mantelet (GM) ## "recent" History * Sep.-Oct. '24 * text reverted to REC-ConeSearch-1.03 (including Errata - 3x) * clarified unique result RESOURCE * MAXREC added with SR=0 metadata overlap (see below) * RA \& Dec decimal flexibility (float []and[] double) * UCDs ported to UCD1+ * July '25 ([https://github.com/ivoa-std/ConeSearch/pull/64)](https://github.com/ivoa-std/ConeSearch/pull/64)) * (Sec.2 main numbered list to subsections) * adding RESPONSEFORMAT * reworked successful response * changed error response to follow DALI behaviour * including OVERFLOW * RA \& Dec decimal degrees response mandated * drawbacks? * MAXREC \& SR metadata enquiries: clarify (see at bottom) * the current footnote needs anyway a small tweak, e.g. * from: "...MAXREC is optional and thus []SR=0 needs to be accepted[] for metadata probing." * to: "...MAXREC is optional while []SR is mandatory, that means that SR=0 must be set[] anyway for metadata probing." **This PR#64 has been updated with running meeting solutions and merged into the current document under development** ## Issues remaining (and already set in the repo) * Clear path * Resource registration ([https://github.com/ivoa-std/ConeSearch/issues/62)](https://github.com/ivoa-std/ConeSearch/issues/62)) * move SimpleDALRegExt-1.2 Sec. 3.1 in Cone Search or refer to it? * in both cases do minor updates to SimpleDALRegExt be needed? **Ongoing discussion happening on the issue page as well as the proposed "draft" pull request.** **Goal seems to be: ConeSearch refers to SimpleDALRegExt, the latter goes under Erratum to clean the reference** **Pull request #67 created and merged** * OpenAPI document ([https://github.com/ivoa-std/ConeSearch/issues/63)](https://github.com/ivoa-std/ConeSearch/issues/63)) (move to discussion) * add it to a non-normative Section or in Appendix or another, connected document? * .xsd \& .vor updates ([https://github.com/ivoa-std/ConeSearch/issues/38)](https://github.com/ivoa-std/ConeSearch/issues/38)) * fix VOTable example ([https://github.com/ivoa-std/ConeSearch/issues/18)](https://github.com/ivoa-std/ConeSearch/issues/18)) * "easy" additions * ConeSearch resource IVOID in response ([https://github.com/ivoa-std/ConeSearch/issues/59)](https://github.com/ivoa-std/ConeSearch/issues/59)) - DataOrigin * https explicit ([https://github.com/ivoa-std/ConeSearch/issues/48)](https://github.com/ivoa-std/ConeSearch/issues/48)) **Already fixed in a pull request merged alongside custom parameters clarification and suggestion** * Discussion topics * custom \& optional parameters behaviour ([https://github.com/ivoa-std/ConeSearch/issues/17)](https://github.com/ivoa-std/ConeSearch/issues/17)) * => add an informative message in the response **see here above, fixed** * main ID usage ([https://github.com/ivoa-std/ConeSearch/issues/53)](https://github.com/ivoa-std/ConeSearch/issues/53)) * "unique" mean unique in the table or dataset collection * Issue and text to review ; this should be solved for v1.1 * [MT] the text is a bit half-baked as it stands: it says the ID "could be used to retrieve that same record again from that same table" but it doesn't say how, so this uniqueness requirement is not very well-motivated. * ConeSearch as a TAP profile? * currently has not an issue attached, needs some discussion/agreement * [MT] I think no. People doing TAP services will figure out how to make a ConeSearch service from them. **dropped, as well as never set as an issue** ## Other "small" things (came up while reworking PR#64) * missing DALI \& SimpleDALRegExt in the architecture schema * refer to architecture v.1.2 * VOUnits * check services to see what their responses do with RA, Dec datatypes * what are the constraints for the potential other table response formats? simply undefined? * a question for DALI, more general than ConeSearch alone * VOTable MIME-type prescription order? * Allowing a 2nd RESOURCE for a datalink service descriptor? * Yes, it is allowed. After the document is WD mature: check implementations and validator(s). #### NOTE: "2.0" \& "time" labelled issues should \_really\_ go to the major revision specification. (meaning also that, when the ConeSearch-2.0 repo will be created, those issues will move there) ## MAXREC \& SR - metadata search A 1.03 client (app-1.03) can only query metadata using the SR=0 solution (metaquery-1.03). A 1.1 client (app-1.1) can query metadata: * with SR=0 only (metaquery-1.1-sr0) - discouraged * with MAXREC=0\&SR=0 (metaquery-1.1-all0) - clear, even if it looks redundant, but SR is a MUST * with MAXREC=0\&SR!=0 (metaquery-1.1-odd) - do you see a use case for this? technically possible, but... What should be servers (1.03 and 1.1) responses? * metaquery-1.03 * server-1.03: OK, metadata response * server-1.1: OK, metadata response with version alert? (an INFO?) * metaquery-1.1-sr0 * server-1.03: OK, metadata response * server-1.1: OK, metadata response with deprecated alert? (an INFO?) * metaquery-1.1-all0 * server-1.03: OK, ignore MAXREC, metadata response * server-1.1: OK, metadata response * metaquery-1.1-odd * server-1.03: OK, ignore MAXREC, but data response * server-1.1: syntactically OK, useless?, but behaviour undefined and metadata response Note: unless apps claim their version compliance, there's no way for a server to distinguish among metaquery-1.03 and metaquery-1.1-sr0, thus a "version alert" might be unfeasible (use "deprecate alert" in both?). In conclusion, to close the client-server-client roundtrip, we need a solution for the metaquery-1.1-odd case: * forbid: server-1.1 returns an error: should both app-1.03 \& app-1.1 need to be able to read it? * allow: server-1.1 returns a data response with QUERY\_STATUS=OK and an INFO alert? aligns app-1.03 and app-1.1 responses but overrides MAXREC=0 and OVERFLOW behaviour from DALI (unclear to MM the "server may try to execute and MAXREC=0 fails" situation described in DALI) Note: reminder, MAXREC is optional (a SHOULD in 1.1) and will not be applied by server-1.03 anyway. ## General notes * > RA \& Dec decimal degrees response mandated * > drawbacks? * MM has checked several services from the registry and it seems to be fine : most services use decimal degrees * MAXREC \& SR * [GM]: any parameter is 0 => returns metadata ; discourage SR=0 * [TJ]: * In SIA1, multiple functions are covered by the size parameter including searching for ‘matching’ images or constructing images of that size. The standard explicitly states: * *A special case is SIZE=0. For an atlas or pointed image archive this tests whether the given point is in any image. For a cutout or mosaic service this will cause a default sized image to be returned. The default image size is service-defined and may be a value considered appropriate for the service, for the given image or data collection being accessed, or for the object (if any) at the given position.* * So for SIA1, size=0 cannot be used in place of MAXREC=0 to ask only for metadata. So do we want to have cone use SR=0 in that way? Personally, I’d prefer that MAXREC=0 be used to fetch metadata in all cases to avoid confusion. (What does a cone search do when SR=0? TBD. Input coordinates within the uncertainty to catalog point coordinates, i.e., the closest you can get to an exact match? Another question.) * [GL]:.. * [MT]: If clients ask for MAXREC=0 and SR<>0 they're asking a weird question - I don't think it matters much if they get a weird answer. * Conclusion: change the concerned paragraph into: any of MAXREC and SR is equal 0 should return metadata * OpenAPI: * Discussion to have about case folding for parameters (RA; DEC; ...): * should we set upper or lower case? * In 1.03, all parameters are in upper case but one has to check the text into details to see if there is any constraint about it. * check to do with validators? * [MT] As far as I can see the text only uses RA, DEC, SR in upper case so (unlike DALI-compliant standards) we don't have a case-folding issue here, upper case is mandatory. That should make the OpenAPI authoring straightforward in this respect. * [TJ] (from chat): Drat, I have to go. I added something I wanted to ask about, namely the fact that the current standard (unless I’ve missed an update) doesn’t allow a service descriptor to be added to cone results because it allows only one RESOURCE. Can we change that? HEASARC’s cones are all failing because of this. * [MT] Answer: in PR#64 this is explicitly allowed: *'There must be a single RESOURCE with type="results" in the VOTable, and that RESOURCE must contain a single TABLE. Additional RESOURCE(s) are allowed to enable, e.g., DataLink service descriptors.'*