Hi Benjamin,
> I agree on that defining what's core and what are extensions in the
> language could probably be a disadvantage for certain services having
> needs we didn't (or even couldn't) think of now.
> However, imo defining the language as one big monolithic block is not
> the best approach to solve this problem. By defining ADQL in a very
> modular way, each service definition could then pick some of these
> modules and define them as "required" for the service, leaving the
> remaining modules "optional" or "extension".
We have no objection to services providing flexible subsets of ADQL; it's just that we don't believe the *language definition* is the right place to put a distinction/set of distinctions that apply to *services*. It gets painful when language and service specifications get interconnected too tightly (think of the versioning problems etc with the coupled ADQL / SkyNode definitions).
The IVOA is currently developing a capability mechanism to describe what services can do, and I think capabilities are the right place to describe modular subsets of ADQL that services might support.
Kona
-- Kona Andrews kea-at-roe.ac.uk AstroGrid Project http://www.astrogrid.org IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJReceived on 2006-11-14Z13:57:57