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).