Core vs Extensions in data services

[Kona Andrews]

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 3HJ