*IVOA DAL WG Running Meeting #7
*Wednesday 27 January 2021 - 11:00 UTC - vconf

Participants: (10) Marco Molinaro, Anais Oberto, James Dempsey, Laurent Michel, Markus Demleitner, Dave Morris, François Bonnarel, Gregory Mantelet, Brent Miszalski, Ada Nebot

Agenda:
	1. ConeSearch
	2. ADQL
	3. Miscellanea 
	4. GitHub notifications to list (if time allows)

*Notes:
*1. ConeSearch
	1. UCD vs. UCD1+ switch issues & concerns (refer issue 20: https://github.com/ivoa-std/ConeSearch/issues/20)
		1.1.  ~7% (~1600) of services use both ID_MAIN & meta.id;meta.main (i.e., there are two different columns, one with the old and one with the new one)
		1.2. ~20 services use both POS_EQ_*_MAIN & pos.eq.*;meta.main (all of them on VizieR -- let's ask them)
		1.3. OBS_ANG-SIZE hardly used, phys.angSize;obs not used
		1.4.  TOPCAT & PyVO seem to work properly with both UCD flavourings
			1.4.1. [MD] PyVO seems to only consider the UCD1.0 format ucds to detect pos columns
			1.4.2. [MM] PyVO stills sems to be able to find pos columns when they only have the UCD 1.1 ucds though - maybe using a partial match?
		1.5. Only needed to skip 3% of services in queries (i.e. 97% of services could be automatically queried)
		1.6. [MM] WIll alert DAL mailing list to these stats and will then move ConeSearch standard to UCD 1+ and report back
		1.7. [MM, MD] Will directly contact some of the services which use other than UCD 1.0
	2. dedicated deprecated section
		2.1.  extra-query-args (HTTP-POST, VOSI/DALI endpoints)
		2.2.  error response
		2.3. [MM] WIll raise an issue for this refactor and notify the list - will proceed after 7-10 days unless objections are received

[GM] Should we be adding sort requirements ing to the spec?
[MD] Probably not - would make implementations less stable and complex, keen not to add it to this revision. If a client needs sorting they should be using TAP

*2. ADQL
General progress can be followed on the GitHub Project #1 (https://github.com/ivoa-std/ADQL/projects/1)

1. Progress since last Interop
  * `UNION`, `INTERSECT`, `EXCEPT` #20 (https://github.com/ivoa-std/ADQL/issues/20)
  * String functions #46 (https://github.com/ivoa-std/ADQL/pull/46)
    * Add `upper('...')`
    * Fix BNF for `lower('...')` _(it was not declared in the BNF)_
    * Fix BNF for `ILIKE` _(it was still a reserved ADQL word)_

2. Catalog of UDF still in RFC. What is its status?
[MM] GWS has verbally agreed to the RFC so it should be approved at the next TCG meeting.

3. Recommendation about case-folding of identifiers. ADQL-2.1 or next version? (see on GitHub #47- https://github.com/ivoa-std/ADQL/issues/47)


4. Look at the suggested CAST solution on GitHub #11 (https://github.com/ivoa-std/ADQL/issues/11)

*3. SODA, TimeSeries, ... (miscellanea)
+ SODA: 1.0 spec is fully in GitHUb now : time for PR, towards 1.1 !!!
   - priorities to define : pixel cutouts ?
                       virtual data generation (see hips2fits, skyview)?
                       selections : FITS extensions ? subparts of measurement sets, polarization parameter ?
                       MOC parameter (also for SIA2)
+DataLink : nothing changed since December. Test implementation of templating in Aladin planned. 
                  Paul Harrisson more radical change for Service Descriptor not discussed yet.
+ TimeSeries discovery and access : upgrade ivoa note (MM,FB, 2018), and then push issues on various protocols : ConeSearch, SIA2, SODA, DataLink ,          ObsCore extension in parallel (DM work)        

[MM] Have a custom merging (regrid and transform) service for one of the ViaLactea data sets. Is SODA the best place for this? Could it be standardised or should we be providing a custom datalink ? Regridding might be on energy or spatial axes. Needs to take in up to four dataset ids.
[FB] SODA allows mulitple IDs
[MD] If you only have one client then there isn't a need to standardise. Doesn't fit into either datalink or SODA very well.
[FB] Can you share a link to the service so we can have a look
[MM] Will add link to service and client to notes 
	[MM: addition post running meeting] Here (http://vlkb.dev.neanias.eu:8080/) you can find a quick description of the VLKB services ongoing setup that includes also the merge solution (the dedicated client is here: https://github.com/NEANIAS-Space/ViaLacteaVisualAnalytics).

[FB] What to standardise has also come up in the radio context with discovery of visibilities. Adding a functionalityto SODA interface to produce an image from the visibilities would be an example of where it wouldn't make sense to standardise as they are fairly bespoke.  Selecting some fields or spectral windows from a multi-filed-SW visibility measurement set however can be of general interest in SODA.

[MM] Would be good to have this SODA/Timeseries/Datalink again at the next running meeting at the US friendly time (would be late night for Europe).

*4. (if time allows: GitHub notification to list) 
[MM] Ran an experiment of notifications from github to a mailing list. Didn't work out well as the emails were just a list of commits and wouldn't be of wide interest. So was considering using GitHub webhooks to implement custom filtering. This has a maintenance overhead - need a service etc

Concerned that the group seeing repo actions and attending running meetings is fairly small. Would like to get activity information to a wider audience.

For now will stop work on mailing list but keep an eye on the audience.

[FB] Agree, we may be losing some people.
Suggets that editors provide a periodic summary email ot the mailing list on activity, maybe include links to PRs etc. Probably too much work for DAL chair to do so needs to go to editor.
Not sure when to use Slack - feel it overlaps with email. 
[LM] Use of slack/email down to preference - different people 
[MM] Use of DAL slack is light - only running meetings 
[GM] Agree author/editor notify mailing list
[GM] Would be nice to have a document describing what to do, particualrly with github with advice on how to do it, and listing what is possible to do (but not mandatory)
[DM] +1
[JD] +1 but need someone to maintain it
[MM] Standards and processes document needs updating could host these
[MD] Working group chairs tend to learn by doing. Clear guidance would be good.
IVOATexDoc might be somewhere to hold this. (assistance with maintenance welcome: https://github.com/msdemlei/ivoatexDoc.git)
Could have "It is a matter of courtesy to notify the group mailing list of PRs"
[DM] +1
[DM] Is this a manual about using the ivoatex document generator, or a manual of advice for IVOA editors ?
[DM] Mixing the two might not be a good idea
[DM] An IVOA note is a good idea, but combining them .. possibly not.
[MD] IvoatexDoc already exists and is maintained - doesn't need a new document.
[DM] How would a new joiner know to use it? The title has to reflect something like "advice for ivoa document maintenance process". Advise people where to raise issues, how to contribute
[MD] Yes that is probably a new document, but the editor advice (e..g mail list notifications) would still fit in ivoatexdoc
[GM] Agree probably two documents, second one (e.g. github guidance) could be a wiki
[AN] +1 on wiki particularly