Allowing optional extended fields in UWS job listings

[Markus Demleitner]

Dear Colleagues,

On Wed, Jul 16, 2025 at 05:00:10PM +0000, Stelios Voutsinas via dsp wrote:
> My proposal is to extend the specification to optionally include
> additional fields from JobSummary in job listings.

This sounds like an eminently understandable thing to want, and
retrospectively I wonder why ShortJobDescription was introduced in
the first place, since even the JobSummary-s will be rather compact.
And if you actually have millions of jobs, where the size difference
might matter, you would want some paging interface whether or not you
have JobSummary-s or ShortJobDescription-s.

Well, there *is* one aspect: I think the ShortJobDescription-s are, in
principle, universally shareable (so you *could* show everything a
service has in its queue in {async}), whereas I suspect many of our
users would not be comfortable having their JobSummary-s public
(which, full disclosure, they are with DaCHS' UWS as long as people
do not authenticate).

In practice, I don't think that's an issue: I'd be surprised if there
was a UWS server-side implementation that shows everything on {async}
to authenticated users and then only starts access control at the job
level.

> This could be implemented through optional schema elements, or if
> for some reason that breaks compatibility for clients, perhaps an
> alternative could be using query parameters (GET
> /{jobs}?include=startTime,endTime,parameters).

*In theory* <http://ivoa.net/documents/Notes/XMLVers/>, clients ought
to ignore elements they don't know, so somehow extending
uws:ShortJobDescription should work if clients are implemented by the
book.  I'd expect you'd be seeing warnings, but that doesn't hurt too
much.

However, for aesthetic reasons I can't say I like the idea of pulling
stuff from JobSummary into ShortJobDescription.  Let's not duplicate
such things without dire need.

I also like client control over responses, because that allows
(relatively) safe extensions.

So... what about defining a new element uws:jobSummaries and saying
that {async} returns uws:jobs by default, but clients may pass in a
GET parameter ?summaries=1 and then *may* get a uws:jobSummaries
element back?

Re-reading this, I'm not too fond of that either, because in the VO,
we have this somewhat odious but *soooo* convenient habit of
generally treating GET and POST analogously, and so defining
different semantics for parameters per method (which we'd do in that
way) sets a precendent that we perhaps don't want to set.

So... what if we had a separate endpoint?  You'd have {async} to POST
to and pull uws:jobs from, and you'd have a job-summaries (probably
literally named that) sibling endpoint to pull job summaries from.
I'd probably even make that mandatory for UWS 1.2 so clients can rely
on it once they have established a minimum version server-side.

Opinions?

       -- Markus