SCS2: Text error messages; New: VERB

Mark Taylor m.b.taylor at bristol.ac.uk
Wed Jul 8 14:37:51 CEST 2026


On Tue, 30 Jun 2026, Markus Demleitner via dal wrote:

> hope for Pat's DALI-text spec and move on to the next item in
> Stelios' list:
> 
> > 4. VERB semantics
> >
> > The spec says VERB must be "supported" but then says: "It is legal
> > to always return the same set of columns independent of the value
> > of VERB." which seems to undermine the parameter's usefulness.
> >
> > If implementations can treat VERB=1 and VERB=3 identically, clients
> > cannot rely on VERB to reduce response size.
> >
> > How about specifying the minimum column requirements per VERB level
> > (e.g., VERB=1 MUST include at least the three core columns, VERB=3
> > MUST return all columns the service holds) and specifying that the
> > default when VERB is absent is equivalent to VERB=2?
> >
> > Either that or why don't we just deprecate VERB entirely?
> 
> Well, I would have liked to drop VERB, as I don't think there have
> been many conscious uses of it.
> 
> On the other hand, I found the objection at the Interop convincing
> that modern large-scale catalogues tend to have hundreds of columns
> and having a way to control the chattyness *for them* would really be
> useful.
> 
> I buy that (although I can only encourage everyone to adopt arrays,
> which often help keep metadata schema sizes sane).
> 
> So, turning this around: Is it bad if clients "cannot rely on VERB to
> reduce response size"?  What could they do if the could?  If you are
> retrieving a catalogue that only has 10 columns, would you care?
> 
> If you'd like to make this a bit more formal, one could formulate a
> monotonicity condition: "Services must return all columns present in
> VERB-1 at VERB (and may add more)" or something like this.  But even
> there I'm couldn't give a strong reason to require this
> (cf. <http://blog.g-vo.org/requirements-and-validators.html>).
> 
> So... perhaps we can leave VERB as it is?

+1 on leaving it as it is.  Yes VERB is ignored by some services, 
but nothing breaks in that case.  It's useful as a non-binding hint.
I don't think anything would be gained (except keeping the validator 
authors in work :-]) by imposing hard requirements on how services
have to interpret it.

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/


More information about the dal mailing list