Let's have a "warning" INFO

[msdemlei]

In particular in the context of the discussion on enabling major version transitions https://github.com/ivoa/major-version-transition a facility would really handy by which services could send warnings to clients; these would, for instance, be raised as python warnings in pyVO, dumped to stderr by clients like stilts or shown in some non-modal way in aladin.

The main use case from a transition perspective would be pushing messages like "this interface will close in 2027; migrate to this other interface until then". But of course this would also be useful in, say, TAP services to warn users doing clearly unwise things that just might be on purpose (but probably are not).

I'd say an INFO with a name of "warning" (case-sensitive) might do. And we could describe it right after the errors subsubsection (i.e., a new 5.4.3, making the additional information 5.4.4).

I'd be happy to provide a PR if there's rough consensus.

[msdemlei]

Oh, as an example for what I consider a good UI for showing warnings in a GUI consider the dillo web browser https://dillo.org/. That has a warning (actually: error, but we're talking about HTML here) icon with an error count at the right end of its status bar (that's a 3 at this time with ivoa.net). Not too obtrusive, but still reasonably visible to elicit curiosity.

[pdowler]

This sounds like a good idea. Hopefully clients won't just ignore warnings.

as an aside: are we explicit about other INFO element names (and in some case values) in terms of case-sensitive or not?

[msdemlei]

On Thu, Jun 12, 2025 at 10:36:37AM -0700, Patrick Dowler wrote: pdowler left a comment (ivoa-std/DALI#60) This sounds like a good idea. Hopefully clients won't just ignore warnings. as an aside: are we explicit about other INFO element names (and in some case values) in terms of case-sensitive or not?

Not yet, I think. To my surprise, neither does data origin. How could that have slipped my review? We should, anyway, and they should be case-sensitive. I give you that ought to be the default and go without saying, but when there's all-caps, I can see how people will be tempted to assume case folding.

[mbtaylor]

This could be done by just adding a new value "WARNING" (upper case, to match the existing permitted values OK, ERROR, OVERFLOW) for the value of the QUERY_STATUS INFO currently defined in Section 5.4. That INFO is allowed to appear multiple times (there may be an OK at the start of the table and an OVERFLOW at the end) so flagging a deprecated interface could coexist with its current use to flag overflow.

FWIW any value other than OK for this INFO is already displayed, next to the row count, in the top-level TOPCAT window for that table - the main intention here is to show OVERFLOW status if present. Whether we do this by extending QUERY_STATUS or in some other way, I should probably improve the way this is displayed.