<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Dear Stelios, Markus and all,<br>
<br>
I like this idea of improving error messages by standardizing them
with some<br>
well defined vocabulary. Whether or not having a subtype, I'd say
that simpler<br>
is generally better. I'd be in favor of "ERROR_TYPE" while not being
wild against<br>
the subtype element. Maybe the main type and subtype can be just a
way to<br>
organize the vocabulary document.<br>
<br>
<blockquote type="cite">So it would be great to find a way forward
on this if this seems reasonable. (<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;">The
full discussion is in the GitHub issue if anyone wants more
context on this</span>)</blockquote>
<br>
For those which do not follow GitHub notifications for DALI, here is
a pointer to<br>
the mentioned GitHub issue: <a
href="https://github.com/ivoa-std/DALI/issues/62"
class="moz-txt-link-freetext">https://github.com/ivoa-std/DALI/issues/62</a><br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 17/07/2025 09:15, Markus Demleitner
via dal wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20250717071537.y7m6uzhpqqmpwgb6@victor">
<pre class="moz-quote-pre" wrap="">Dear Colleagues,
On Wed, Jul 16, 2025 at 04:52:46PM +0000, Stelios Voutsinas via dal wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""><VOTABLE>
<RESOURCE type="results">
<INFO name="QUERY_STATUS" value="ERROR">Query exceeded processing time limit</INFO>
<INFO name="ERROR_TYPE" value="resource-limit"/>
<INFO name="ERROR_SUBTYPE" value="time-limit-exceeded"/>
</RESOURCE>
</VOTABLE>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">[...]
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Markus suggested this might be a good candidate for a standard
vocabulary, which makes sense to me. And the approach seems
extensible enough that we could add new error types later without
breaking anything.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Actually, I was suggesting to *only* have ERROR_TYPE and make its
value controlled by a vocabulary. In that way, thanks to the
hierarchy of the vocabulary, services can communicate types and
Stelios' subtypes in one go. A part of the vocabulary could, for
instance, be:
resource-limit-exceeded
time-limit-exceeded
disk-limit-exceeded
network-transfer-limit-exceeded
request-string-too-long (though that probably ought to be HTTP-level)
client-error
parameter-syntax-error
bad-adql
missing-parameter
...and so on.
If a server says
<INFO name="ERROR_TYPE" value="bad-adql"/>
a client that has first-hand knowlege of that term knows that there's
no point re-submitting this query (at least to that server) and
specifically, that their users need to check their query syntax.
Less sophisticated clients might only classify by the top-level
concepts, and I claim finding these is easy to do; cf.
<a class="moz-txt-link-freetext" href="https://ivoa.net/documents/Vocabularies/20230206/REC-Vocabularies-2.1.html#tth_sEc3.2.2">https://ivoa.net/documents/Vocabularies/20230206/REC-Vocabularies-2.1.html#tth_sEc3.2.2</a>
Basically, when the error type is in error_type and you have a dict
of predefined reactions error_actions, you would write something
like (actual Python):
# Fetch the vocabulary
import requests
voc = requests.get(
<a class="moz-txt-link-rfc2396E" href="http://www.ivoa.net/rdf/error-type">"http://www.ivoa.net/rdf/error-type"</a>,
headers={"accept": "application/x-desise+json"}
).json()
# find the most specific reaction ofr error_type
while error_type not in error_actions:
error_type = voc["terms"][error_type]["narrower"][0]
error_actions[error_type]()
This will raise an IndexError if no appropriate action can be found,
but that's easy to change.
If good terms for that error-type vocabulary cross your mind while
you're thinking about this, please let me know.
Thanks,
Markus
</pre>
</blockquote>
<br>
</body>
</html>