*ADQL: Status & Discussion
*(Thursday May 7 - 6:00 UTC)

*Participants: 39

*Session notes:
	* Useful links:
		* Updated ADQL-2.1 (PDF): https://seafile.unistra.fr/f/a86414352c3447ffb59b/?dl=1
		* Issue Board on GitHub: https://github.com/ivoa-std/ADQL/projects/1
		* Introduction slides: https://wiki.ivoa.net/internal/IVOA/InterOpMay2020DAL/adql_2.1_status.pdf
    
1. ADQL-2.1 Status 
	* 2.1 has been in draft for 4 years. Time to wrap it up, resolve last remianing issues and release to PR/REC

2. GitHub usage 
	* Issues being recorded in Github, hot topics 'pinned' by Grégory
	* Grouping issues into projects, focus willbe ADQL 2.1 project

3. What is done 
	* IN_UNIT #18
	* DISTANCE #28
	* misc - Issues 15, 19, 31

4. Work in progress 
	* Boolean #32 - five proposed solutions
		* Jesus: CONTAINS as boolean can not be backwards compatible. Should it be for an ADQL major version?
		* [MD] : Could write the grammar such that both CONTAINS options are valid, but it is worth it?
		* [Gregory] Probably not worth doing now that 1= syntax is already widely used
		* [Igor C] in fact, “CREATE OPERATOR” in postgres uses a boolean function underneath
		* [Grégory] Prefer to not change this at this stage now.
		* [Mark T] It sounds complicated to do, was one of the original proponents, now that not the recommended XMATCH syntax probably not a priority
	* Coord Transform #10
		* [Igor C] I would comment here: when we were working on pgSphere almost 20 years ago, we implemented operators for “contains” and “is contained” — this would solve the problem automatically
		* [Jesús S] Yes. This could work, Igor
		* [Alberto M] How do the UDFs work? 
		* [Marcus D] Came form RegTapExt requirements, waiting for TCG endorsements, some compatibility functions which a user can expect if any of them are declared.
		* [ALberto M] ESO has some custom functions declared in their capabilities
		* [Marcus D] Yes a good idea to include them, but for next rouond post RFC
	* Geometries arg. #29
		* 
5. To do
	* UNION, INTERSECT, EXCEPT #29
	* CAST v Constructors #11
		* 
6. After ADQL-2.1. . .
	* 

*Questions:
	1. Grégory:  What should be a reasonable period of time before the approval of a PR (Pull Request) and its merge and closing the corresponding issue?
	1. Grégory: Is the collaboration on GitHub OK for everyone? If not, what could be improved? 
		2. Markus: my main concern is that it effectively locks out the public.  While, of course, I'd generally prefer it if we ran the discussions using IVOA tools and open protocols, I think one mitigation might be to have a robot that posts each PR to the DAL list as it is posted.
		2. Markus] Could put admin and trivial changes into master and leave pull requests to other changes so that can send PR to DLA list
		2. [James, TIm J] Best to have everthing via PRs
		2. [Mark T] Don't want robot posts to the DAL list - will likely ignore DAL list if lots of robot spam
		2. [Markus] Retract proposal - suggest onus on the editor to forward appropriate PR notifications to the list from their feed of all PRs
		2. [TimJ] I’ve also had a positive experience of linking GitHub to Slack and having a dedicated slack channel reporting merges and pull requests
(I realize that doesn’t help Markus)
		2. [Pat] We have tried automated notifications (github->slack,  github->email, CI->email) and it usually only takes a few days before I have to implement an email filter or unsubscribe from the channel... note that a PR doesn't mean the issue is fully decided and accepted for even a WD being promoted to Proposed Rec -- that process remains the same and the wider community will review/critique the full document, not the github activity. A PR being merged into master means the authors have agree/comprimised.
		2. [FB] my point from experience with DataLink. For small changes (issues) group several in one PR and editor advertize times to times ofsuch PR on the mailing list. No robot, and group the issues. But yes more report of the github activity on the lists
	1. Grégory: Does everybody agree for an Erratum to ADQL-2.0 to make the coord. sys. argument just a literal in `CIRCLE` & co?
		2. [Pat] This would also effect user tables that are uploaded - those could have coordsys in a column
		2. [Marcus] COuldnt see how it would work
		2. [Grégory] COuld have the calculation the DB
		2. [Marcus] Would prefer the erratum be made as noone is likely implementing this properly.
		2. [Marco] Suggest Grégory writes the proposed erratum for discussion.
	1. Grégory: When is the PEN Catalogue of UDFs no longer Proposed?
		2. When TCG (WGs at least) review and vote
	1. Grégory: Should we have boolean values in ADQL-2.1? If yes, which solution? (see Issue 32 on GitHub: https://github.com/ivoa-std/ADQL/issues/32#issuecomment-618476985)
	1. Grégory: CAST or datatype constructor?
	1. [Gregory D-F] BOX function deprecation was planned what happened? [Grégory] Was not compatible with pgsphere etc [Igor C] PGSphere also has rectangle operator [Marcus D] Was too much work to implement to be worth it? [Gregory] Often misunderstood as opposed to RANGE from SIA2 which is generally understood (problems regards near poles). [Marco] Wasn't this moved to DALI leaving ADQL free of this? (regions x-types)
	1. 
	1. 

[Igor C] Units and formats (re CAST and IN_UNIT)- can define coordinates as a string, can define units in the string, cast to circle, can then define output formats with units too. Perhaps looks at it is done in modern databses to inform the ADQL proposal.
[Grégory] Already informed by PGSphere. Planning to keep a unique way to describe units.

[Alberto M] Wanted to implement an intersection fucntion that returned the intersection.
[Marcus] Can now define this as a UDF, prefer to prefix like eso_intersection 
[Igor C] It’s hard to define the output type for the intersection
because it’s not a polygon if you intersect a polygon with a circle