Core vs Extensions in data services
kea at roe.ac.uk
Tue Nov 14 04:57:40 PST 2006
> 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 Andrews kea at roe.ac.uk
AstroGrid Project http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ
More information about the voql-teg