Updated SLAP2 document

[nicolasmoreau]

Document has been updated following what has been discussed during the May 2025 DAL meeting.
Valid response example in appendix B is still missing

[msdemlei]

(1) Do not define the macros ivoaBaseURL and following in the document. They are managed by the Makefile in gitmeta.tex. If you include that, you're fine. Out of curiosity: What made you define the macros yourself?

(2) Also, don't usepackage{geometry}. I wonder why this works in the first place, because the class already does that. If you have to change the page geometry, use \newgeometry (but please avoid that if you can).

(3) "Fully compliant services will also provide the {species} resource". For one, I'd suggest calling that an "endpoint" rather than a resource despite the practice in DALI (where it should be fixed, too; I've filed a bug to this effct). But in particular, I'd avoid any notion that there's "fully compliant" or "partly compliant". That's not useful: Either a client can rely on a facility or it can't. Let's make up our minds whether every SLAP2 needs a species endpoint or it doesn't (and that depends on what we'd like that endpoint to do: Translation service (no) or species directory (yes)).

(4) I'd say you register the lines endpoint access URL and force the names of the other endpoints. I don't see how this could be trouble. But that's just a matter of taste perhaps. Anyway, clients should not have to fetch the capabilites for simple operations.

(5) Most importantly, and I'm adamant on this: Use DALI interval syntax to write intervals. No slashes, please. We've had enough chaos with these, now let's just do what DALI says even if we don't like it (I don't very much, admittedly, but it's the least bad option we could come up with).

(6) Let's make MAXREC a must; actually, I'd probably require many more of the protocol parameters, basically all for which there's not a strong reason why operators might not support them. Constraints on columns people must have anyway IMHO are not of that sort.

(7) Use the \ucd macro to mark up UCDs. It'll help you down the line with more consistent typography and fewer overfull hboxes.

(8) Please don't invent new INFOs when Data Origin already has them. Ideally, for now either pick a few of them or reference the note.

(9) "A standard column could appear multiple times with different units." sounds like a terrible idea. How should this even work? You can't have multiple column with the same name. No: Unit conversion is client work.

[mbtaylor]

There are several invalid UCDs in this document, though I haven't checked if they are all introduced by this commit, they may have been present in earlier versions. Examples: "phys.atmol.ionization", "em.line;meta.id.cross", "em.wl.central;meta.id.cross", "spect.line.width;meta.unit", "spect.line.intensity;stat.snr"; mostly the problem is that a secondary atom is in the primary place (e.g. "meta.unit;spect.line.width" would be OK).

[gpdf]

I’d like to reinforce Markus’ comment on the syntax for interval-valued parameters. Please use the DALI syntax.

I was struck by that the current PR is actually actively moving away from DALI to a “/“-based syntax. I’d be curious to know what was driving that.

In any event, the DALI format is supported now by numerous community tools that are already able to provide Python interfaces and/or UIs on top of query parameters in this form, without requiring service-specific knowledge. Let’s keep building on that.

I do notice that the syntax documented in the earlier version is not pure DALI interval, but is rather more like the hybrid “point or interval” parameters in the SIAv2 standard. The “/“-style parameter in the PR retains this feature as well. Does this sort of parameter need to be explicitly supported in DALI? Or are we trying to move toward a query parameter syntax that handles that by saying (as DALI already does) “if you want a scalar rather than an interval, just provide a degenerate interval” (e.g., “FOO=1.71 1.71”)? (See also ivoa-std/DAP#15 )

If the community really wants the SIAv2-style point-or-interval syntax, I think we need to codify in DALI a way to have those be self-identifying in service descriptors.

[nicolasmoreau]

I’d like to reinforce Markus’ comment on the syntax for interval-valued parameters. Please use the DALI syntax.

I was struck by that the current PR is actually actively moving away from DALI to a “/“-based syntax. I’d be curious to know what was driving that.

In any event, the DALI format is supported now by numerous community tools that are already able to provide Python interfaces and/or UIs on top of query parameters in this form, without requiring service-specific knowledge. Let’s keep building on that.

I do notice that the syntax documented in the earlier version is not pure DALI interval, but is rather more like the hybrid “point or interval” parameters in the SIAv2 standard. The “/“-style parameter in the PR retains this feature as well. Does this sort of parameter need to be explicitly supported in DALI? Or are we trying to move toward a query parameter syntax that handles that by saying (as DALI already does) “if you want a scalar rather than an interval, just provide a degenerate interval” (e.g., “FOO=1.71 1.71”)? (See also ivoa-std/DAP#15 )

If the community really wants the SIAv2-style point-or-interval syntax, I think we need to codify in DALI a way to have those be self-identifying in service descriptors.

I think you read an older version of the document. Indeed interval were defined with a / character ( which came from the 2019 version of SLAP 2 ) but this was modified following the remark of Markus.

The document now explicitely references DALI on this subject in the Input Parameters section (4.2) :

Query parameters for text or string fields are always case-sensitive and indicate an exact match.
Query parameters for numeric fields accept a single numeric value or a range
of values with optional lower and upper bounds such as defined in the DALI specification