<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p></p>
<div>Hi Markus,</div>
<div><br>
</div>
<div>Thanks for the feedback and the analysis.</div>
<div><br>
</div>
<div>I probably agree that mixing JobSummary fields into ShortJobDescription isn't ideal, and also see the complexity of adding a query parameter that when used return a different schema. I think ideally I would see merit in removing ShortJobDescription altogether
in favour of just a using JobSummary, but since this breaks compatibility it's probably a major UWS version upgrade (several years) away, if we even agreed that that would be a good approach.</div>
<div><br>
</div>
<div>Your separate endpoint suggestion does seem like the least painful approach. A /{jobs}/summaries endpoint that returns JobSummary elements would solve our performance problem and maintain those schema boundaries. It would probably make sense that it supports
the same filtering parameters as the current endpoint.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>The only sticking point I see is the optionality of this, and how we tell providers to advertise this in the capabilities/registry. I'm thinking we could extend VOSI capabilities having this as an additional interface to indicate support, so clients can
gracefully fall back for services that haven't implemented it yet.</div>
<div><br>
</div>
<div>What are your thoughts on <span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">
how this should be advertised to clients and generally on the</span> implementation timeline?</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Stelios Voutsinas</div>
<p></p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> dsp <dsp-bounces@ivoa.net> on behalf of Markus Demleitner via dsp <dsp@ivoa.net><br>
<b>Sent:</b> Thursday, July 24, 2025 12:34 AM<br>
<b>To:</b> dsp@ivoa.net<br>
<b>Subject:</b> Re: Allowing optional extended fields in UWS job listings</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Dear Colleagues,<br>
<br>
On Wed, Jul 16, 2025 at 05:00:10PM +0000, Stelios Voutsinas via dsp wrote:<br>
> My proposal is to extend the specification to optionally include<br>
> additional fields from JobSummary in job listings.<br>
<br>
This sounds like an eminently understandable thing to want, and<br>
retrospectively I wonder why ShortJobDescription was introduced in<br>
the first place, since even the JobSummary-s will be rather compact.<br>
And if you actually have millions of jobs, where the size difference<br>
might matter, you would want some paging interface whether or not you<br>
have JobSummary-s or ShortJobDescription-s.<br>
<br>
Well, there *is* one aspect: I think the ShortJobDescription-s are, in<br>
principle, universally shareable (so you *could* show everything a<br>
service has in its queue in {async}), whereas I suspect many of our<br>
users would not be comfortable having their JobSummary-s public<br>
(which, full disclosure, they are with DaCHS' UWS as long as people<br>
do not authenticate).<br>
<br>
In practice, I don't think that's an issue: I'd be surprised if there<br>
was a UWS server-side implementation that shows everything on {async}<br>
to authenticated users and then only starts access control at the job<br>
level.<br>
<br>
> This could be implemented through optional schema elements, or if<br>
> for some reason that breaks compatibility for clients, perhaps an<br>
> alternative could be using query parameters (GET<br>
> /{jobs}?include=startTime,endTime,parameters).<br>
<br>
*In theory* <<a href="http://ivoa.net/documents/Notes/XMLVers/" id="LPlnk498599" previewremoved="true">http://ivoa.net/documents/Notes/XMLVers/</a>>, clients ought<br>
to ignore elements they don't know, so somehow extending<br>
uws:ShortJobDescription should work if clients are implemented by the<br>
book. I'd expect you'd be seeing warnings, but that doesn't hurt too<br>
much.<br>
<br>
However, for aesthetic reasons I can't say I like the idea of pulling<br>
stuff from JobSummary into ShortJobDescription. Let's not duplicate<br>
such things without dire need.<br>
<br>
I also like client control over responses, because that allows<br>
(relatively) safe extensions.<br>
<br>
So... what about defining a new element uws:jobSummaries and saying<br>
that {async} returns uws:jobs by default, but clients may pass in a<br>
GET parameter ?summaries=1 and then *may* get a uws:jobSummaries<br>
element back?<br>
<br>
Re-reading this, I'm not too fond of that either, because in the VO,<br>
we have this somewhat odious but *soooo* convenient habit of<br>
generally treating GET and POST analogously, and so defining<br>
different semantics for parameters per method (which we'd do in that<br>
way) sets a precendent that we perhaps don't want to set.<br>
<br>
So... what if we had a separate endpoint? You'd have {async} to POST<br>
to and pull uws:jobs from, and you'd have a job-summaries (probably<br>
literally named that) sibling endpoint to pull job summaries from.<br>
I'd probably even make that mandatory for UWS 1.2 so clients can rely<br>
on it once they have established a minimum version server-side.<br>
<br>
Opinions?<br>
<br>
-- Markus<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>