UDF catalogue Proposed Endorsed Note: Request for Comments

This PEN proposes a mechanism for listing ADQL extension functions that are requried to work the same way across different data centers. It is a supplement to the ADQL standard, and currently there's text in ADQL 2.1 referencing it.

The latest version of the UDF catalogue can be found at: http://ivoa.net/documents/udf-catalogue/

Version control: https://volute.g-vo.org/svn/trunk/projects/dal/udf-catalogue

Reference Interoperable Implementations

As to the endorsed content, there should always be at least two services carrying the functions. Regrettably, the required RegTAP res_detail table doesn't carry UDF names (there's always a use case exactly for the most exotic feature you can think of), so to find these services, you'll have to rely on volutary extra keys parsed by the services.

The RegTAP service at http://dc.g-vo.org/tap parses the extra res_detail. Use a query like

select access_url
from rr.res_detail
natural join rr.interface
natural join rr.capability
where detail_xpath='/capability/language/languageFeatures/feature/form'
and detail_value like 'ivo_healpix_index%'
and standard_id='ivo://ivoa.net/std/tap'

Implementations Validators

Not really applicable here. It might be nice to have a few standard queries per function with the intended results, but since ADQL doesn't have queries without from clauses and there is essentially no content in the underlying databases you can rely on, they're really hard to write.

Perhaps a case for an ADQL extension: Facilitate writing tests?

Comments from the IVOA Community during RFC/TCG review period: 2020-02-15 .. 2020-03-30

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

• Sample comment by WikiName
  • Response (by WikiName)

• Comments by GregoryMantelet :
  • ivo_apply_pm(...) : currently, it is in the "HEALPIX-related" section, but it is not Healpix related. I suggest to move it in a different section (e.g. "Coordinates") or to rename the "HEALPIX-related" section into something more generic.
  • ivo_healpix_index(spoint, ...) : rename the 1st argument - spoint - by point or something else that does not make think about the datatype spoint of PgSphere
  • gavo_transform(from_sys, to_sys, geo): what are the allowed syntaxes for the two 1st arguments? Can the equinox be specified in there?
  • Maybe few examples can be added to functions. It could be helpful for implementers (especially for gavo_transform(...) )

Comments from TCG member during the RFC/TCG Review Period: 2020-02-15 .. 2020-03-30

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

TCG Chair & Vice Chair

Applications Working Group

Data Access Layer Working Group

DAL is happy with the goal and main content of this Note and will be happy to support its Endorsement provided that the following comments are taken into account and fixed in the document.

1. purely technical: the .pdf and .html available online and linked at the top of this page lack the internal references and references list. We suspect this is due to some issue in building them, since building the package from scratch from the svn provides them and fixes what looks like a locale issue in the version control metadata.
2. general remark (also arisen by G. Mantelet above): examples of usage of the functions would be really valuable.
3. Sec. 1 (Introduction), second paragraph ("In order to..."): this sentence is quite long and difficult to follow. We'd like it clarified and the reference to ADQL to be like "starting from ADQL-2.1" or "ADQL-2.1 and subsequent versions". We suggest a look at current wording in ADQL-2.1 (currently here: https://github.com/ivoa-std/ADQL/pull/26/files) to align the PEN statements.
4. Sec. 1 (Introduction), third paragraph ("This note documents..."): also here we'd like some re-wording, plus we don't agree on the safety of having the maintenance devoted to svn commits (slightly better if GitHub issues) when the normative list actually comes from RECs and the non-normative comes from Registry harvesting (actually the MOC related UDF come from neither one...). We suggest to fix this by stating something on the implementation of these UDFs: if they come from RECs reference is in the REC, if they come from TAP service homogenization please list the providers previously using them (like gavo_ + cds_ -> ivo_) to understand where the norm comes from. At that point maintenance will be just a matter of re-checking/updating the Note on a regular basis or at REC issuing.
5. Sec. 1 (Introduction), fourth paragraph ("Note that no function..."): we are not sure stating a "must" is part of an EN, we suggest, again to try to harmonize the sentence to the vision the ADQL text reports: this is a best practice, for everyone to follow.

Other than the above some typos or clarification requests (some other, minor, sent to authors directly) are listed here:

• Sec. 2: maybe "precision" rather then "length" of (REAL) floating point values
• 2.1.1 ivo_healpix_index: ra/dec vs. long/lat parameters differ in the text w.r.t. the signature
• 2.1.2 ivo_healpix_index: hpxOrder missing in signature, reference to PgSphere spoint (see G. Mantelet comment)
• 2.1.4 ivo_apply_pm: tangential plane, we suggest usage of the pmra description w.r.t. the introductory one
  • if it's independent on the frame, why no use lat, long, pmlat, pmlong, or, highlight the "Note that..."
• 2.2.2 ivo_nocasematch: please reword the "In ADQL 2.1 and later, use the ILIKE operator instead." into a more soft "Please consider that...suggest usage of ILIKE" or the like.
• 2.3.1 ivo_interval_overlaps: the shortened param names lead to typographical ambiguity on the "l" and there's a double "h1" in the signature. lowerN, higherN would be better?
• 2.3.2 ivo_interval_has: we'd prefer longer param names for better readability
• there are 2 appendixes "A"
• A1.6 is it really a 13c_angpix function? We suspect a typo

Data Model Working Group

Grid & Web Services Working Group

Registry Working Group

Semantics Working Group

Data Curation & Preservation Interest Group

Education Interest Group

Knowledge Discovery Interest Group

Solar System Interest Group

Theory Interest Group

Time Domain Interest Group

Operations

Standards and Processes Committee

TCG Vote : Vote_start_date - Vote_end_date

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.