ADQL-2.1 PR now available

[Mark Taylor]

On Thu, 25 Jan 2018, Markus Demleitner wrote:

> Well, yes.  But I'm unhappy with 4.2.15 (the section defining COOSYS)
> anyway.  First: 
> 
>   "Details of the coordinate system for a database column are
>   available as part of the service metadata, available via the
>   TAP_SCHEMA tables defined in the TAP specification and the /tables
>   webservice response defined in the VOSI specification."
> 
> That's not true -- neither currently has a means of communicating
> machine-readable information on coordinate systems, and teaching it
> to them would at least double the specification length for either of
> them.  

good point.

> I'd say (and DaCHS does this[1]) that coordinate system metadata
> simply is part of the response.  This currently means that in VOTable
> reponses, people should include COOSYS, and there was STC-in-VOTable
> (which was almost universally ignored), and perhaps some day there'll
> be STC2 and the mapping spec. 
> 
> Given the depressing state that STC in the VO still is in, I'd say
> ADQL shouldn't add any further confusion and just say:
> 
>   4.2.15 COORDSYS
> 
>   COORDSYS was intended to let clients extract a coordinate system
>   identifier from a geometry.  Implementors SHOULD, where available,
>   still return the coordinate system identifier when the geometry in
>   its argument was constructed with a meaningful one and NULL in all
>   other cases.  Clients are advised to avoid the use of this
>   function.  
>   
>   This function is marked as deprecated by this specification and may
>   be removed in a future version.

Yes, I prefer that.
 
 
> > 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 http://dc.g-vo.org/tap 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.

> But not even in the HTML/CSS community, many orders of magnitude larger
> and better funded than we are, does this work terribly well.  I keep

(I suspect that it's *easier* rather than harder to do this in a
smaller community).

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/