ADQL-2.1 PR now available

Marco Molinaro molinaro at
Mon Jan 29 09:24:30 CET 2018


> > > sec 4.3.1:
> > >     A reserved namespace is proposed:
> > >
> > >        "The ivo prefix is reserved for functions that have been
> > >         defined in an IVOA specification."
> > >
> > >     I think that's not a bad idea, but I believe that in
> > >     at least some cases current practice violates it; the DaCHS
> > >     service at defines e.g.,
> ivo_healpix_center,
> > >     ivo_interval_overlaps, ivo_healpix_index, ivo_apply_pm.
> > >     I've heard Markus defend that practice elsewhere, so I guess
> > >     he should comment.
> >
> > Well... As usual we don't really have a process for how to phase in
> > these things, and "IVOA specification" isn't a well defined term
> > either (WD?  PR?  REC?  Note?).
> I don't think this would be hard to do, if we wanted ivo_ to mean
> "defined in an IVOA specification" as per the current text.
> The rule in practice could be that if the intention is for
> a given UDF to end up in a REC, then it can have the ivo_ prefix.
> So ivo_ is fair game for inclusion in any standards-track
> document (WD, PR, REC, or pre-WD, or sketch on a napkin of what
> a WD might look like one day), and not otherwise.
> It might result in some ivo_* UDFs getting provisionally defined
> and then later retracted or changed, but I don't think that's
> a disaster.
> > The way I'd like this to work is: If two or more implementors agree
> > on a function pattern (which was the case for the healpix functions,
> > but admittedly not for apply_pm), they'd use ivo_ and ideally put up
> > their proposal for discussion here.
> I mildly prefer the in-a-standards-track-document rule I've outlined
> above, but I don't have very strong views.

I'm replying with the simple idea of reminding that

gives some hints on the startup of this process.

I agree that simply saying "specification" is a bit unclear.
If we keep the above wiki page clean, a reference to it
may be a (temporary) solution.

Letting ivo_ prefix available to implementors agreeing
each other doesn't feel right to me, it sort of bypasses
the working group collaboration or discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the dal mailing list