In my opinion (since I am working on a TAP implementation right now) it is currently possible for the TAP spec to say that:
That is exactly where "required", "recommended", and "optional" should be specified. He is correct that implementors could chose to support POINT, CIRCLE, and POLYGON but not REGION, but that depends solely on the TAP spec and not on ADQL.
As for ADQL creating some new geometry types, that is actually necessary. If we only had REGION(<string>) then there would be no feasible way for the TAP service (database) to expose it's own positions and shapes as columns. Everyone would have to expose a very complex DB schema and the query would have to construct an STC region from multiple columns, bringing in all the problems he keeps expressing with his POINT('ICRS', t.ra, t.dec) example. I looked down that road and it is a huge disaster of string concatenation and inability to index anything effectively.
We cannot make everyone 100% happy with ADQL (including me) but we have found a middle ground.
PS-we agreed in trieste to rename the coord extraction functions: are we going with CVAL1 and CVAL2? It seems the only choice that doesn't imply anything about the coordinate system.
-- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2008-07-04Z20:17:58