Allowing optional extended fields in UWS job listings

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Mon Aug 4 14:52:34 CEST 2025


Hi Stelios,

On Fri, Aug 01, 2025 at 08:08:26PM +0000, Stelios Voutsinas wrote:
> Are you thinking this would be an optional endpoint in the next
> minor version of UWS? Potentially with a plan to make it mandatory
> eventually?

I suppose adding this and issuing UWS 1.2 would probably not meet much
resistance.  If it works just as well as the current jobs resource,
it would be nice if we could eventually replace the old jobs
resource; but I don't see a way to do that without a breaking change.
That would mean that 1.3 would be UWS 2.0, and the summaries in
themselves don't seem enough of a rationale for a major version
transition to me.

Making job-summaries mandatory in, say, 1.3, I'd see as a lot less
critical if we have good rules for how 1.3 clients can interoperate
with 1.1 services.

> The only sticking point I see is the optionality of this, and how
> we tell providers to advertise this in the capabilities/registry.

Ach!  It would be nice if we had DALIInterface or some other way to
represent the more complex interfaces we now have
<http://ivoa.net/documents/caproles/>.  I'd totally be in on an
attempt to finally address the pains described in Caproles.

As long as we don't have that, I'd first see how far we get with what
we did for, say, examples in TAP: Just rely on 404s to be returned
when the feature is not there.  Yes, it's an extra request, but 404s
tend to be cheap on the server side.

The likelihood that a service already has job-summaries next to async
but doing something else is so low that I think the 404-based method
is actually fairly safe.

If this really doesn't work out, I'd say that's a clear indication we
have to go on with DALIInterface.

Thanks,

         Markus



More information about the dsp mailing list